这还是很早之前参与创业的时候,专门写的用于同行交流用的,针对一个真实的手游项目进行的测试分析,这里备份一份,权当锚点:
一、服务器的网络底层架构
目前服务器采用的是基于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写模拟器机器人,针对游戏测试过程中的重点操作情况进行压力测试,同时,使用封测、公测的方法使用真实玩家做较为完整的压力测试。