性能测试(也称为负载测试)是一种有用且强烈推荐的方式,用于验证服务器端的实现,和硬件是否可以实际处理预期的负载(在线人数)。

您的期望是什么?

我们经常被问到一个简单的问题就是:一个光子服务器可以处理多少个并发用户(CCU)?

但是如果要认真考虑这个问题,那么这个答案并不是那么简单。因为它取决于多个因素,例如:

  • 每个房间的人数
  • 传递消息率(每间房间和每秒的消息量合计)
  • 通讯量的大小
  • 协议类型(可靠Reliable/不可靠Unreliable)
  • 客户的平台
  • 采用服务器硬件规格
  • 等等
在一个典型的案例中,我们假设需要处理的量为:约200消息量/房间/秒。

在如下的标准配置中:

  •  四核CPU(例如Intel Xeon E3-1270 v3、3.5GHz)
  •  8 GB RAM
  •  1 GBps NIC /上行链路端口速度
在标准配置中,每个配置Photon的服务器可以处理2000-3000 CCU

通常情况下,瓶颈不是CPU运算能力,而是NIC/带宽大小。 因为流量通常比高配置的CPU更贵,因此可能使用较低配置的服务器通常效率更高。

而且一般而言,实体物理服务器比VM(虚拟云服务器)提供更好的结果。

但是,上面的数字只是对预期结果的粗略估计。 您需要使用自己的代码库进行一些调整并运行负载测试,以获得适合您自己的项目的可靠数字。

确定测试方案

在运行负载测试之前,请预估您的项目运行环境并进行预先计算。

  • 您希望服务器是什么硬件规格?
  • 您希望自己的游戏有多少CCU(同时连接数)?
  • 您是哪种类型的游戏,配对会如何进行?您是否具有用于不同功能的不同服务器?
  • 您是使用Photon Server SDK中未经修改的代码,还是拥有自定义代码? 如果有自定义部分,主要修改是什么?
  • 每间客房有多少位用户?
  • 有多少条消息要被传递?
    •  示例:4个用户/房间,每100ms调用RaiseEvent() 
      •  传入:4 * 10 msg / s = 40 msg / s
      •  传出:4 * 40 msg / s = 160 msg / s
      •  总计:200消息/房间/秒
  • 平均消息大小是多少?
    •  例:
      •  200消息/房间/秒 * 200byte=〜40kByte/秒/房间
      •  预期:1000 CCU / 250个房间=>〜10 Mbyte / s 总计

使用上面示例中的计算,您的项目已经接近100 MBit / s上行链路端口速度的上限。

我们几个客户端库具有内置的“网络流量统计信息”(Network Traffic Stats),可以帮助您回答这些问题。

建立一个测试客户端

光子是专门为处理大量的连接和流量进行优化的, 但是,客户端SDK和库并不是设计来用于进行负载测试的。一般案例中也无法以与Photon相同的方式对客户端进行优化。

不建议的设置:实际的游戏客户端和服务器通过“某些网络”进行连接

在大多数情况下,要准备要运行负载测试时,一般您的“游戏客户端”已完成。 因此,您可能会认为,将真实的游戏客户端用于负载测试是更加简单的做法。 但是,如果您尝试使用PhotonSDK的“负载测试客户端load test client”,则这些客户端将成为瓶颈,您将获得不准确且令人误解的结果。

建立一个好的测试客户端,是负载测试的真正挑战。

我们建议采用以下方法:

  •  记下游戏客户端需要发送的典型操作/事件的顺序。
  •  构建一个简单的Photon Server(!)应用程序,模拟游戏客户端的行为。
  •  使用Photon的服务器到服务器(Server to Server)功能在“S2S负载测试应用程序”和“服务器端” 的两个Photon应用之间建立连接。
推荐:Photon Server应用程序使用(S2S)连接进行测试负载平衡之Photon主机

配置光子

Photon / PhotonServer.config

  • 使用默认配置,请勿进行任何更改。
  •  默认配置针对各种用例进行了优化。 任何更改都可能产生不可预见的影响,并且将使理解和分析测试结果变得更加困难。

记录/ log4net.config:

  •  确保在所有log4net.config文件中使用“ INFO”日志级别。
  •  在“ DEBUG”级别上过多的日志记录会对性能产生巨大影响,因此需要避免使用!
  •  在此处了解有关日志的更多信息:https://logging.apache.org/log4net/release/config-examples.html

运行测试

  • 将您的Photon S2S负载测试客户端托管在单独的物理计算机上。
  •  根据经验,每个光子的“服务器端”至少需要两台“ S2S负载测试机”才能平均分配负载。

在运行测试之前,请确保在服务器端和客户端计算机上安装性能计数器(Performance Counters)并创建性能计数器日志:

  1.  如果光子正在运行,请停止它
  2.  从Photon Control->性能计数器(Performance Counters)->安装计数器(Install Counters),创建日志集(Logging Set)
  3.  从命令行启动“ perfmon”。 在“data collector sets”->“User Defined”下:在“右”窗格中选择photonperflog>“Properties”->将采样间隔设置为1秒(如果采用默认的间隔1分钟,则没有足够的数据)
  4.  启动光子
  5.  Photon Control -> Performance Counters -> Start Logging
  6.  运行负载测试(load test)
  7.  Photon Control -> Performance Counters -> Stop Logging
  8.  从c\perflogs\admin获取性能日志
  9.  从\deploy\bin_win64\log和\deploy\log获取日志文件

如果从Photon Control创建计数器日志失败,请从\deploy\bin_tools\perfmon运行以下命令:

logman.exe create counter photonperflog -si 00:01 -v mmddhhmm -cf logman.config.txt

分析性能并确定瓶颈

要分析负载,请在perfmon中加载性能计数器日志(performance counter log)。

在Photon Server SDK的“ doc”文件夹中,有一个“ photon-perfcounter.pdf”文件,其中列出了所有计数器并对其进行了简要说明。

  1.  估计“总体”负载:对于首次估计,请查看“明显Obvious”计数器,例如:CPU load, number of Peers / Connections Active, memory usage per process, disconnects, network traffic (Bytes in / out / total) 等。 这些计数器可以使您了解服务器是否按您之前预期方式处理负载,或者是否存在需要进一步调查的瓶颈。
  2.  传出流量(客户端忙吗?): 如上所述,客户端通常是瓶颈。 请检查“传出”流量是怎样被处理的,例如“重新发送的命令每秒”的数量(如果客户端不发送ACKs,则Photon重新发送该命令),“已排队的可靠命令(Queued Reliable Commands)”的数量(已发送的命令的数量,尚未确认)等等。 如果这些值很高,则很可能您存在客户端的问题。 无论如何,您都应该仔细检查并确认这些计数器,如果您发现了客户端的瓶颈,请解决它并重新运行测试。
  3.  传入流量(服务器忙吗?): 通过比较当前正在“处理”多少个“Active” I/O,业务和ENet线程(Business and ENet Threads),以及ENet队列中是否有消息等项目,来检查服务器是否繁忙。 这些计数器通常与CPU /内存使用的计数器相关。

error: 转摘请联络我们~