游戏性能排查
阅读本文大概需要15分钟
本文将帮助您快速查看游戏客户端性能数据、服务器房间数据及房间实时日志。
【性能数据】主要分为客户端、服务端,其中客户端提供了玩家设备性能统计数据及报错数据,服务端提供了实时日志及服务端性能;
客户端性能
本部分提供了平均帧率、平均ping值、平均内存、DrawCall等客户端性能指标,表现玩家在玩游戏时客户端的性能情况,其中只有平均帧率是越高越好,其他指标都是越低越好,点击【游戏数据】-【客户端性能】查看。
- 平均帧率:每秒能够渲染的帧数;
- 平均ping:游戏中延迟的程度;
- 平均内存:游戏运行内存占用;
- 平均DrawCall:CPU调用图形渲染接口的次数,该数值越高用于渲染的开销越高;
- 游戏线程平均耗时:每一帧用于游戏内Tick事件,角色动画更新,物理计算,UI更新等的总耗时;
- 渲染线程平均耗时:每一帧用于进行场景的剔除,准备渲染数据和渲染命令等的总耗时;
客户端指标怎么看
这部分的指标是小时级更新,根据查询时间的不同返回不同维度的数据,当跨天查询时,返回天级数据,同一天查询时,则展示小时级数据。
从箱型图中,可以看到该时段上报数据的中位数、上四分位数、下四分位数、最大值、最小值和异常值。
中位数用来表示数据的整体趋势:中位数高,表示平均水平较高,中位数低,表示平均水平较低;
上下四分位数的差可以表现数据的离散情况:箱子短,表明数据集中,箱子长,表明这组数据分散;
例如图中,在当日22时,游戏的运行内存中位数是506.07,上四和下四分位数分别是649.88和429.40。
客户端指标怎么优化
帧率过低、平均Drawcall过高、平均内存过高、游戏线程平均耗时过高、渲染线程平均耗时过高都可以参照以下内容统一优化解决思路。
Tips1:减少场景里的模型数量
- 尽可能减少场景里面的物体数量,能用一个物体的就不要用多个;
- 比如地板,可以用平面+贴图,不要一个一个方块地去“贴地砖”;
- 又比如房屋,能用现成的房屋就不要从地板、墙面、楼梯、天花板一个一个搭;
Tips2:提高模型的复用率
- 提高场景里模型物件的复用率,如用于场景装饰的箱子等,可以在不同地方多次出现;
Tips3:少用半透、植被相关资源
- 少用这类带性能标识的资源,这类资源带有mask材质,会导致游戏产生性能风险,能不用就不用;
Tips4:多用低面数的模型代替高精建模
- 三角面数过多,手机负担过大,场景建模建议多用lowpoly相关的;
- 能用基础模型就不用lowpoly,能用lowpoly就不用写实风格;
Tips5:适当减少场景里的npc人型对象
Tips6:代码层面要简化
- 代码里尽量少写死循环,少用性能消耗高的API ,如RPC、Replicated相关的、换装同步、高频循环等;
报错数据
报错数据会聚合最近一天/一周玩家游玩游戏时的报错信息,按照报错类型聚合影响用户数及报错次数;
点击【查看】即可查看报错日志时间流,具体影响的用户信息及详细报错日志信息;
房间管理
功能概述
房间数据部分提供实时房间&玩家数据,可以查看分时/分日的数据变动趋势,以及每个房间的实时日志。
【游戏服务】-【房间服务】可以查看所有游戏整体房间数据情况,点击【查看】即可进入游戏房间列表。
房间列表
房间列表可以按照状态(运行、销毁、异常)查询每个房间&玩家行为,同时支持查看每个房间的性能监控;
实时日志
可以通过实时日志打印房间日志信息,找到当前房间号点击【实时日志】,即可打印&下载服务端房间日志;
游戏代码编写时可以通过Log或Error来区别打印日志,通过日志等级(Log、Error)、类型或关键词等过滤无关信息;
- MWTSLIB日志类型:编辑器底层打印的日志(TS层调用接口查找一个对象超时也可能反应在这里)
MWTS日志类型:TS代码层调用引发的日志
关于TypeError类的报错,这种一般是由于我们代码自身写出了bug导致的报错,代码里查找一个guid为55555的对象,当然是无法找到这个对象的,而后续逻辑里没有对这个对象进行判断就直接调用方法设置位置,自然就会报错,而这种报错类型通常就含有关键字TypeError,这种类型的错误也是开发者应该重点关注的;
服务端性能
点击【房间列表】-【服务端性能】可监控当前房间的服务端性能,最多支持查询24小时内数据,统计时间间隔支持5秒-5分钟;
字段 | 纵轴单位 | 指标介绍 | 简要介绍 | 优化case | 备注 |
---|---|---|---|---|---|
服务器内存 | MiB | 使用:进程实际使用内存情况限制:使用上限,超出内存会出现崩溃 | 服务器根据房间最大人数来分配内存,房间最大人数*40M | 场景合并,控制动态对象数量减少不必要的全局常量定义使用对象池不使用的对象destroy掉 | 重点关注 |
服务器CPU | C | 使用:实际使用服务器CPU限制:分配cpu使用上限 | 房间最大人数*0.02 | 减少update执行量考虑分帧执行提高cpu的使用效率,当cpu在执行一块逻辑时,特别是循环遍历时,当数据的物理地址不是连续的时候会降低cpu的执行效率,这个对应客户端的cpu也是适用的减少网络请求 | 重点关注 |
服务端帧率 | 帧/s | 使用:服务器当前帧率 | 最高30帧,也就是正常情况下每帧的执行时间为0.033 | 同CPU,当CPU执行一遍的时间大于0.033时,帧率就会降低,优化CPU消耗 | 重点关注 |
RPC函数调用 | 次数 | 使用:每秒PRC(远程过程调用)调用次数 | 服务器与客户端函数调用频率建议控制在20/s*最大玩家数RPC过多会导致CPU和带宽的增长 | 减少rpc的调用,对于频繁的改动,使用属性同步合并请求,在下一帧使用一个rpc函数传输同时需要考虑多玩家都在进行RPC双端可以保存自己的数据,不用频繁同步(如在使用道具时,客户端判断条件,使用消耗,同时发送给服务器,服务器验证消耗) | 重点关注 |
在线玩家 | 人数 | 使用:当前房间在线的人数 | 当前房间玩家数,范围5-50,游戏设置里配置 | 人数越多,分配的内存与CPU也多,但消耗也就增多,需要根据项目情况做好设计平衡 | |
同步对象数量 | 数量 | 使用:每秒同步多少对象到客户端 | 同步对象数量增多会导致CPU和带宽的增长 | 减少双端动态对象,玩家登陆时同步量会很高,将场景双端对象通过逻辑分开逐步添加,使用属性同步时可以分帧 | |
网络带宽 | Mbit | 输入:服务器的输入流量 输出:服务器的输出流量 | 服务器发送给每个客户端的带宽总量:100kb/s*最大玩家数rpc与同步对象占用 | 优化rpc频率优化同步对象数量优化rpc中数据总大小 | |
网络传输包 | 个数 | 【输入,输出】束,协议包数量, 【输入,输出】包, 具体分成多少协议包发出 | 网络传输包是进行数据传输时的基本数据单元,包含元数据和数据部分,通过网络传输到目的地并在目的地重新组合成完整的数据。网络传输包过多会导致:网络延迟增加网络拥塞能耗增加(移动端) | 尽量避免发送重复的数据 合并传输包可以是一种有效的优化方式,可以减少网络传输过程中的延迟和能耗,同时降低网络拥塞的风险。 合并多个小的网络包成为一个较大的网络包,可以减少网络通信的次数,从而减少网络延迟和网络拥塞的风险。此外,较少的网络通信也可以降低移动设备的能耗,延长电池寿命。 当然也要考虑合并传输包的容量大小,不能超过网络连接的缓冲区大小。 | |
丢包 | 个数 | 服务器没有收到ack,重发的丢包数量次数 | 丢包可能原因是多方面,包括网络波动,或是因为通道阻塞造成的丢包,再者损坏的数据包被拒绝通过 | 降低数据发送频率 | 主要都是网络原因造成的 |