游戏服务器性能测试之阈值问题

一、前言

游戏服务器性能测试中会遇到很多的知识点,我也是在努力学习中,在这里把工作中学习到的知识进行一下总结。本篇介绍一下服务器性能测试过程中的一些阀值问题。后续的文章中将持续介绍服务器架构相关,压测工具相关的内容。

游戏服务器性能测试之阈值问题

二、网络层的阀值和安全问题

玩网络游戏打本、组队、交流、体验各种交互玩法,都是建立在网络通信之上的。因此有一个稳定服务器是必要前提,而网络层作为最基础、最核心的模块往往需要经过层层考验。下面就是一些网络层会涉及到的问题和阀值相关内容。

1、最大TCP连接数

Linux系统对用户单一进程同时可打开文件数量是有限制的,网络通信中每个建立的链接都需要一个文件句柄,因此单个进程可接受客户端的连接数量是有上限,默认值一般为1024(可以通过命令 ulimit -n 查询)。如果在压测过程遇到服务器只能与特定数量的客户端建立连接时,可以看看这个值是否正常。

2、网络协议包大小限制

在进行网络通信时,协议包的长度限制也是需要注意的。客户端与服务器通信的单个包一般需要设置一个阀值,当收到客户端过大的协议包就可以断开连接,并记录相应的异常日志。
假设不做限制,客户端可以给服务器发送任何大小的包。如果恶意给服务器发送一个1G甚至更大的包,服务器就需要对应大小的内存才可以读取出来。
首先会造成服务器性能被大量消耗在数据读取上,其次是造成大量的内存分配可能导致服务器因内存不足而崩溃。
另外,如今服务器很多都是分布式的,内部会有多个节点进行网络数据通信,这些节点之间的数据通信往往可以不与客户端使用相同大小的包限制(并非绝对如此),内部节点可以适当放大协议包的大小。

3、网络协议包接收队列阀值

服务器处理每条协议需要消耗时间和资源,针对每个连接设置最大待处理协议包接收阀值也是一种保护手段。当某个连接发送的数据包过多时,则可以断开这个连接(一般这种属于恶意攻击或者业务设计问题)。
如果一个客户端疯狂的发协议包给服务器,服务器全部资源都用于处理这个客户端的请求,那么将导致服务器无法及时响应其他客户端的请求,导致其他客户端都处于无法正常体验。

4、协议包最好添加包头包尾

这不是必须的,但增加包头和包尾可以使协议交互更加安全稳定。
假设客户端发送了一个长度为N的数据包,由于某种原因长度计算错误(应该为N+4),服务器接收到这个包后就可能将不完整的包给业务层去处理。首先这个包业务层处理就存在一定的风险,再者这个包还有部分遗留在网络接收队列中,导致下一个包处理异常。这种问题一旦是一个偶然引发的错误,那么定位起来就难了。

5、协议加密

外挂是游戏不得不面对的问题,协议安全就是其中一个课题。协议加密并不是越复杂越好。每条协议都需要服务器解密和加密操作,过于复杂的算法会消耗CPU,导致服务器的业务处理能力上不去。在压测的时候会使用加密模式进行,以便可以将服务器这块的消耗也统计在内。

三、功能业务阀值

1、最大注册人数

最大注册人数一般用来限制单个区的注册上限,让用户可以分流到更新的区。特别是有些游戏由于特殊的需求,是必须限制注册上限的。这个就需要我们在压测业务时考虑进去。
我刚进入游戏行业时,公司做的是三国SLG游戏,每个玩家注册进入游戏后会在地图中生成一个城池,如果不设置上限那么最后可能就无法正常注册进入游戏了(地图中的位置数量是固定大小的)。

2、最大在线人数

设置最大在线人数首先可以保证不超过上面说的最大连接数,再者可以保证服务器能在稳定的环境下处理业务。假设服务器承载为1万,设置为5000最大在线,这样可以减少服务器的负荷,也可以确保在线的玩家都可以顺畅的体验游戏。

3、用户排队机制

在游戏登陆中排队我相信大家都遇到过,尤其是比较火的游戏刚开服会进入大量玩家的时候。虽然有最大在线人数做保障,增加用户排队也可以很好的减少服务器在短时间的高负荷,让进入游戏的玩家体验顺畅。

4、可用内存大小

我相信内存泄露这种问题每个开发人员都有经历过。对服务器需要做内存监控,防止业务出现内存泄露导致服务器异常崩溃。在进行压测的之前可以对服务器进行编译时加入内存监控的模块,尽早发现泄露问题并解决它。有些时候也需要通过打印内存快照对比来分析。

5、定时器数量

服务器的业务使用定时器是很平常的事情,但是滥用定时器可能就会导致定时器泄露。定时器中往往会保存一些数据,泄露的定时不仅会导致内存消耗,也会消耗轮训带来的CPU消耗。增加定时器数量监控,可以很好的发现泄露和不合理的业务设计。

6、日志文件大小

 一般很少有游戏服务器会将全部日志写入单个文件,即使是按小时存储日志,也需要考虑大小,否则超出单文件大小限制后就会出现写入失败的情况。尤其是可以通过日志恢复游戏数据的设计方式。

7、交互玩法的上限

游戏中会有各种各样的玩法,能产生性能问题的玩法绝大多数为多人交互型,因此这些玩法都需要考虑是否需要加入上限限制。当然这个限制绝对必须是能够支撑整个玩法后的一个安全值。

以下简单举例:

同时战斗的副本场数 如果副本战斗比较消耗性能,就需要设定同时最大创建副本的数量。
单场景容纳的人数上限 如果一个场景的人数过多,服务器广播的压力就很高,性能消耗也会很高。

四、总结

上限阀值很多时候是为了服务器的稳定和安全做的,正常情况下是达不到这个值的。但如果没有这些上限阀值,意外情况或不法分子就可能会导致服务器问题,从而危及游戏数据安全。另外,应该还有很多其他的会对服务器性能产生影响的点,以上是我暂时想到的一些内容,希望可以对大家有用。

源自公众号 游戏测试开发



留言