服务端在线人数性能测试

因为机器人工具运行时，模拟用户并发登录也会占用大量系统性能，为了避免对服务端产生影响，所以要在两台服务器上分别运行。并且让两台服务器在同一个局域网内，也是为了减少网络带宽的消耗，同时也能减少网络连接不稳定对测试结果的干扰。

多人在线的服务端性能测试方案十分简单，就是在服务端运行时，使用机器人工具模拟大量用户并发登录，直至达到最高在线人数，观察运行状况，收集性能数据。但有几点内容需要知道：

最高在线人数不是一瞬间达到的，服务端同时处理多人登录是有个吞吐量上限的。这个吞吐量决定着运行机器人工具时，每秒要创建登录的机器人数量。一般来说，全量导入的情况下，服务端10分钟基本就可以达到最高在线人数，所以运行机器人工具是并发的频率大致为：最高在线人数/600，单位（个/每秒)。想要更准确的话可以直接问服务端开发人员，服务端每秒能处理并发登录的人数是多少。
服务端刚启动时，要进行大量的数据加载和初始化，所以不要服务端刚一启动，就并发大量机器人进行登录，至少也要等服务器启动后稳定运行10分钟。
新建角色登录比旧角色登录更为消耗服务端性能，所以使用机器人工具并发登录时，每次最好都使用新建账号角色。如果要反复使用同一批账号，每次测试后要删除角色数据库，也就是所谓的“清档”。
在线的机器人角色的行为也会极大影响服务端运行的性能，如果条件允许的话，尽量让机器人角色在做任务打副本，最简单的也要能够移动和释放技能。

知道基本的测试思路和方案后，具体执行如下：

先依次启动服务端，机器人工具和性能采集工具，确认都能正常运行后全部关闭，服务端数据库清档或更换机器人账号。
先启动服务端和性能采集工具，持续运行10分钟，同时收集性能数据，期间不登录任何角色。
使用实际的客户端登录1个角色，跑到机器人将会登录的位置等待，主要用于确认机器人角色是否正常创建登录。
启动机器人工具，按照预定频率，先登录“最高在线人数一半”的机器人角色，持续收集10分钟性能数据。此10分钟内，可用客户端登录的角色在游戏内尝试做任务，打副本，看是否有掉线、响应延迟等问题。
继续将剩余的机器人角色登录进服务器，确认达到最高在线人数后，持续收集10分钟性能数据。此10分钟内可继续使用客户端登录的角色在游戏内进行观察。
关闭机器人工具，持续收集10分钟性能数据。使用客户端登录的角色，观察和确认游戏内的机器人角色是否正常退出。
正常关闭服务端和性能采集工具，检查服务端运行log中是否有报错日志。整理收集到的性能数据，删除无效数据后，制表绘图。
可根据需要调整参数后进行多轮测试，例如提高最高在线人数，提高机器人每秒并发登录的人数等。每次测试前都记得要进行数据库清档或更换新的机器人账号角色。

服务端性能常见的问题表现，主要集中在CPU和内存上，其次就是服务端运行的log日志里的报错信息。这里基于以往的工作结果，仿造一些数据和图标介绍如何分析。

首先，整理收集到的性能数据，结合测试情景，大致能得到如下的格式内容：

数据表主要是用来罗列整体的测试数据，以及与预期数值进行对比的。除非有特别明显的问题，比如内存预期使用的均值为200 MB，但实际测试的值为500 MB，这种差距太大的也是要去定位具体的原因。

上图横轴表示在线人数，纵轴表示服务端CPU消耗。当人数增长到25的时候，代表测试值的红色曲线就已经达到了100%，说明服务端已达性能瓶颈，需要详细查找原因，例如是否是机器人出现大量登录失败或掉线，或者机器人都登录成功了，但服务端运行变得十分卡顿。

上图横轴表示测试时间，纵轴表示内存消耗，测试步骤是前30分钟一直增加机器人登录，30分钟后关闭机器人工具，等待角色全部下线登出。原本角色下线后，服务端应该回收内存，但代表测试值的红色曲线在30分钟后依然居高不下。这就需要与后端开发核对，是否存在内存泄漏。当然，有些服务端架构就是角色下线不回收内存，说是为了下次角色再次登录时不用重新读取数据库，这种情况下就要评估长期累积登录的角色，所占用的内存是否会消耗完所有的系统内存，导致再有新角色登录时因申请不到内存数据而创角失败。

3.2.1. 服务端在线人数性能测试