一份简要游戏服务器缺陷、瓶颈分析报告

  这还是很早之前参与创业的时候，专门写的用于同行交流用的，针对一个真实的手游项目进行的测试分析，这里备份一份，权当锚点：

一、服务器的网络底层架构

目前服务器采用的是基于Boost Asio的网络底层架构，消息处理方式采用：单一服务IO，多线程池实现。

 

基于Boost Asio网络基础库的性能情况：

参考：http://think-async.com/Asio/LinuxPerformanceImprovements，基础测试报告：

server1：a simple single-threaded server. 单线程，单io_service

server2：io_service-per-CPU design. 多线程，多io_service，每个线程处理一个io_service，采用轮询方式选择io_service;

server3：a single io_service and a threadpool. 多线程，单io_service，所有线程都运行在同一个io_service上

server4：a single-threaded serverimplemented using stackless coroutines

测试环境：

Linux 2.6.9-67.ELsmp #1 SMP WedNov 7 13:58:04 EST 2007 i686 i686 i386 GNU/Linux  Intel(R) Xeon(R) CPUE5430 @2.66GHz （参考性能），报告为2007年提出的。

（此测试图较老，大约是0.38版本，若用目前最新的1.53版本，由于asio库从1.45版做了进一步的优化，性能大约会有至少5%-15%左右的提升）

目前服务器采用的是单一io_service加多线程池的实现。若需要进一步提高性能则可采用

Io_service-per-CPU的设计进一步提升基础库服务性能。

 

二、服务器瓶颈分析

1、内存瓶颈分析：

测试工具:massif

测试环境：CentOS5.5(内网测试)

数据文件：massif.out.16293

对比：服务器启动，人数一定情况下不打斗的情况，问题一目了然！（如下图，数据文件：massif.out.25068）

 

此项测试背景：

测试人数：10-15人左右；

测试持续时间：约8小时；

测试目的：获取内存占用问题的真正瓶颈所在。

测试结论：

1、战斗技能相关部分实现不合理，导致内存泄露，且在人数一定的情况下无法稳定在正常范围内。

 

2、战斗创建部分实现不合理，内存泄露较为严重

 

3、背包部分的数据量过大，虽然没有内存泄露的问题，但是由于设计上对于内存的使用没有做相应的优化，且可能存在某些实现不合理的情况，因此背包部分数据量较大，但由于此数据量跟游戏人数有关在人数一定的情况下，内存能够获得稳定范围因此，相较于前两个问题来说，严重层度较低。

 

以下是性能分析部分的样例，目前根据服务器的测试情况，没有较为严重的性能问题，但若由于编码实现不当引起相应的性能问题，亦有相应的工具及手段进行解决。

 

2、性能瓶颈分析:

分析文件：callgrind.out.25565

 

 

三、服务器压力测试方案

         采用Python写模拟器机器人，针对游戏测试过程中的重点操作情况进行压力测试，同时，使用封测、公测的方法使用真实玩家做较为完整的压力测试。