【众多选择】
当前市面上能够提供性能压测的工具很多，选择面也能很广泛，下面我将结合实际具体业务逐一分析和筛选。
TcpCopy
线上引流模式，针对新项目或全新功能就不太合适了，业务层面若需要一定量的业务逻辑支持，很难做得到。
JMeter
Java编写，在执行1万个压测用户线程时，CPU上下文切换频繁，大量并发时会有内存溢出问题，很显然也不是理想的选择。
nGrinder
图表丰富，架构很强大，堆栈依赖项太多，学习成本很高。
需要额外掌握Python等脚本语言，虽针对程序员友好，不是所有人都可以马上修改。
数十个线程至少占用4GB内存，一台机器上要模拟5万个用户，不但CPU上下文切换恐怖，16GB小内存机器更是远远满足不了。
针对服务器资源充足的团队，可以考虑单独机器部署或Docker部署组成集群，针对我们团队情况就不合适了，想免费做到是不可能的。
Tsung
完成同样性能压测功能，却没有第三方库依赖，独立一套应用程序。
虽然所测试服务是I/O密集型，但所占用内存不会成为瓶颈。
可能会触及到Erlang语言，但我们现在工作用的语言就是Erlang，也就不存在什么问题了。
其他
综合所述，Tsung默认情况下消耗低，可充分利用现有服务器空闲计算资源，线上多次实践也证实资源占用始终在一个理想可控的范围内，具有可让百万用户压测执行的费用成本降低为0的能力，这也是我们选择Tsung的目的所在。
【为什么是Tsung？】
Tsung是一个有着超过15年历史积累的性能压测工具，本身受益于Erlang天生支持并发和分布式以及实时性的特性，其进程的创建和运行非常廉价，一台机器上轻轻松松创建上百万个进程。其提供一个用户对应一个进程的隔离处理机制，单机支持虚拟用户的用户数量可支持若十万、百万级别，只要机器资源充足（但总体来讲受制于受制于网络、内存等资源，后面会具体解释）。单机计算能力总是有限的，Tsung的目的就是要把多台服务器横向扩展成分布式集群，从而可以对外提供一致的海量性能压力测试服务。
协议层，Tsung不但支持TCP/UDP/SSL传输层协议等，而且应用层协议，已支持诸如WebDAV/WebScoket/MQTT/MySQL/PGSQL/AQMP/Jabber/XMPP/LDAP等。默认情况下，开箱即用，凭借着社区的支持，市面上能够找到的公开通用协议，都有相应官方或第三方插件支持。
和nGrinder相比，Tsung定位于提供一个强大的性能测试工具，在易用性和强大可扩展方面保持了一个平衡点。基于XML + DSL提供可配置、可编程的能力。比如我们可设置上一次的响应结果作为下一次请求内容，我们可配置多种业务协议、多个业务场景作为一个整体压测等。尽力抽象所要压测的情景吧，你不会失望的。
服务资源占用方面，以单机模拟5万长连接用户为例，有数据正常交互情况下，内存占用不到3GB，CPU占用不到两核，十分经济。
实践压测环节中，可能需要考虑很多的事情：
1. 会不会突然之间对LVS网络通道产生影响，需要和网络组同事进行协调；
2. 会不会因为突然之间的压力导致影响到其他现有服务；
3. 一般建议，非封闭的网络环境下将用户每秒压力产生速度设置小一点，保险一些。
【设计压测会话内容】
压力测试会话内容的编写，有三个原则需要注意：模拟、全面和强度。
我们在设计压测会话时，一定要清楚所开发系统最终面向的用户是谁，其使用习惯和特征分别是什么，一定要尽可能的去复现其使用场景。其次，需要模拟的用户会话内容要全面覆盖用户交互的各个方面，比如聊天室项目中，一个用户从加入房间，中间流程包括点赞、打赏、光柱、发言等行为，中间间隔的心跳等，最后可选择的退出行为，其业务场景，完整的体现在编写的压测场景中了。另外，针对业务场景特点，还针对每一个具体的行为，还要考虑其执行次数等，简简单单走一遍流程，也就失去了性能压力测试的意义了。
性能压测流程驱动
压测之前，我们一般需要关注哪些东西呢，其实大家做法差不多，可以列一个清单：
1. 添加计数器，可以发送到计数收集服务器，报表显示等；
2. 核心逻辑做好日志记录，但日志记录过多时，可能也会成为瓶颈，需要取舍日志等级等；
3. 区分核心模块和非核心模块的在资源紧张时是否需要区别对待等。
压测中，大家一般都是紧密盯着各项报表，查看服务器各项资源开销等。有一点需要强调的是，尽量作为终端用户一员，亲身参与进去，这样才能够切身体验并切切实实感受到此时服务的质量。
压测后，复查各项报表，查看错误日志，结合刚才自身的体验等，认真思考修改问题，然后继续下一轮压力测试啦。
扫一扫
2221
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
