“微博产品后端服务团队在资源受限情况下基于Tsung提供了一套开箱即用的100万用户性能压测工具套件，推动两名能力和经验都欠缺的中初级工程师，不但顺利完成支持海量用户的在线聊天室项目任务，同时保证了该业务系统整体处理性能可控并按照预期方式向前推进。”

　　需求 & 背景

　　前段时间我们为微博App增加一个视频直播聊天室功能，这是一个需要支持海量级手机终端用户一起参与、实时互动的强交互系统，建立在私有协议之上、有状态的长连接TCP应用。和其他项目一样，在立项之初，就已确定所构建系统至少能够承载100万用户容量，以及业务处理性能最低标准。

　　当时研发力量投入有限，一名中级工程师 + 一名初级工程师，两人研发经验和实践能力的欠缺不足以完成系统容量和处理性能的考核目标，这是摆在眼前最为头疼问题。聊天室业务逻辑清晰并已文档化，倒不用太担心功能运行正确，除了自我验证外，还会有QA部门帮忙校验。这驱使我们在软件工程角度去思考，如何通过行之有效的手段或工具去推动研发同学项目顺利完成项目性能考核目标。

　　聊天室会话实例

　　延伸一下，新项目构建之初，自然要关注总体处理性能目标的。但从软件生命周期角度考虑，还应该考虑到系统后续维护和迭代。所谓工欲善其事，必先利其器，因此我们需要提供一个完善的开箱即用、支持海量用户的性能压测基础工具套件，既要能够保证系统处理性能是可测量的，又要能够为每一次版本发布时、常规迭代后再次验证系统性能目标。带着这一目标，下面将逐一展开我们如何构建百万用户性能压测工具套件的过程以及注意事项。

　　性能贯穿于软件生命周期

　　性能压测工具选择

　　团队所能够支配的空闲服务器数量几乎为零，这是现状。所负责业务线的大部分服务器配置为16GB内存、24个CPU核心左右，每时每刻都在跑着具体的业务。若留心观察，一般晚上九、十点之后资源利用率高，而白天时间CPU、内存、网络等资源大概会剩余30%-60%左右，颇为浪费，如何将这部分资源充分利用起来，是一个需要思索的问题。

　　针对100万用户这样超大容量压测需求，要求每台压测机要能够负载尽可能多的用户量。试想，若一台压测机器承载1万用户，那么就会需要使用到100台，单纯所需数量就是一件让人很恐怖的事情。

　　若是单独为性能压测申请服务器资源，一是流程审批流程较为繁冗，二是因为压测行为不是每时每刻都会执行高频事件，会造成计算资源极大浪费。本着节约资源理想方式就是充分利用现有的空闲计算资源用于执行性能压力测试任务。

　　【众多选择】

　　当前市面上能够提供性能压测的工具很多，选择面也能很广泛，下面我将结合实际具体业务逐一分析和筛选。

　　TcpCopy

　　线上引流模式，针对新项目或全新功能就不太合适了，业务层面若需要一定量的业务逻辑支持，很难做得到。

　　JMeter

　　Java编写，在执行1万个压测用户线程时，CPU上下文切换频繁，大量并发时会有内存溢出问题，很显然也不是理想的选择。

　　nGrinder

　　图表丰富，架构很强大，堆栈依赖项太多，学习成本很高。

　　需要额外掌握Python等脚本语言，虽针对程序员友好，不是所有人都可以马上修改。

　　数十个线程至少占用4GB内存，一台机器上要模拟5万个用户，不但CPU上下文切换恐怖，16GB小内存机器更是远远满足不了。

　　针对服务器资源充足的团队，可以考虑单独机器部署或Docker部署组成集群，针对我们团队情况就不合适了，想免费做到是不可能的。

　　Tsung

　　完成同样性能压测功能，却没有第三方库依赖，独立一套应用程序。

　　虽然所测试服务是I/O密集型，但所占用内存不会成为瓶颈。

　　可能会触及到Erlang语言，但我们现在工作用的语言就是Erlang，也就不存在什么问题了。

　　其他