1回答

MMO大世界手游流量超标的问题如何解决？

提问者 yiloghuang 2017-04-01 218浏览

大型多人在线游戏开发 PVP PK 场景

本人所在游戏项目属于MMO大世界手游，目前流量使用存在超标情况，主要场景在于200人同一位置PK，一直释放技能，10min流量大约9MB，流量明显偏高；

游戏技能释放与攻击为无锁设定，均为范围伤害，前端需要同步的数据较多，游戏战斗逻辑是把参与战斗的属性，同步给前端，前端利用这些属性来预判、立即生效技能施法及动作特效的表现。例如：视野范围内有70个玩家，这70个玩家的属性数据，也是需要同步给前端；

这样导致流量消耗过大，目前研发团队优化遇到瓶颈，寻求大牛给予后续优化建议，优化流量使用情况......

收起显示全部

快来消灭0回答吧

{{ dataList.answer_count | view-format }}回答

最热|最新

vwzhengzh 2017-04-01 17:45

常规的优化方向(需基于流量统计清单):
1, 对明显是热点的包id, 做发送频率或包内容的缩减;
2, 对于高频且需要即时发送的包, 尽量将其大小控制在mss/mtu(不大于1400字节比较稳妥)以内或mss的整数倍, 避免过多在ip层拆包加包头带来的开销; (如果项目组是从业务层去统计流量, 这部分开销并不会被统计在内, 但在系统网卡层面应该还是有所反映的)
3, 对于高频但即时性要求不高的包, 考虑在合适的维度上做并包. 比如在九宫格做视野管理方案下, 可以基于视野格做合并; 也就是把一定时长内单个视野格的多个包合并后下发, 下发的触发点可以是合并后大小到达阈值/缓存超时/特定逻辑, 类似于在逻辑层手动处理的nagle算法.
4, 对大包(包括并包), 考虑包压缩

进行了较为详细的沟通后, 了解到基本面如下:
A, c/s之间的通信基于TCP协议
B, 采用九宫格视野管理, 场景格边长6米, 玩家视野半径18米, 视野内同步玩家上限数量70, 混压5000人在线时平均流量625B/s;
C, 玩家发送移动请求频率为5~15次/秒, 每次均会导致广播;

项目组现有的优化机制如下:
A, 针对对象属性同步(广播)包, 尽量合并到1KB之后再下发;
B, 针对玩家属性/状态同步, 进行了简单的分级策略: 第一级基础战斗数据, 第二级修正属性数据; 两级同步频率目前均为250ms; 在属性全同步之后，nav移动信息和技能信息每tick(50ms)同步
C, 协议层使用pb进行序列化和反序列化, 序列化之后的数据并未压缩

针对所了解到的情况, 建议的优化策略如下:
-- [性价比最高] 针对超过某阈值大小的大包, 使用gz压缩, 并通过实测找到合适的压缩比, 在流量和cpu计算量之间找到平衡;
-- [配合压缩策略, 尽量节约cpu] 目前的状态同步广播包与单播包采用相同的协议结构, 建议独立定义简单的广播包结构, 去除大量只在单播中需要的字段, 降低大量广播包的序列化计算成本;
-- 目前的广播分级机制, 在包内容上做了较为明显的区分, 但在逻辑层面还需要细抠, 真正体现出对重要的内容即时发, 对次要或不紧要的内容少发或晚发;
-- 移动信息同步频率过高, 需要与客户端和体验策划紧密配合, 尽量缩小其常规频率; 另外可以考虑动态同步频率, 即根据拥挤程度/cpu压力等易于取得又具备体验指征性的指标, 在高压力时动态降低同步频度, 以在流量/性能/体验之间取得更好的平衡;

0

0评论
{{ answer.user.NickName }} {{ answer.profession }} {{ answer.created_at | time-format }}
专家回答

{{{ answer.answer }}}

点击查看全文

{{ answer.answer_count > 0 ? '收起评论' : answer.answer_count}} 删除修改收起

{{ answer.answer_count | view-format }}评论