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