一.突破客户端端口数限制

• 这是第一个会遇到的问题，同一IP地址，最大端口只能到65535。
• 现在能够直接找到的原因是TCP协议中（rfc793）定义了报头的端口长度为16位。（2 ¹⁶=65536）
• 但是从计算机网络的发展来看，端口长度定义同IPv4定义一样，都是当时的同志们拍脑袋的结果。

突破的办法

• 一个机器绑定多个IP地址。
• 搞无数机器或者虚拟机。

二.防止gc影响测试结论

• 如果压力程序为java，要小心full gc导致单次请求时间加长。
• 从java角度，随时jstat -gcutil跟踪client的情况，很有必要。

一些推荐的参数

• 24G的机器: -XX:ParallelCMSThreads=8 -Xms12G -Xmx12G -XX:PermSize=128m -XX:MaxPermSize=512m -XX:MaxDirectMemorySize=1280m
• 细节慢慢调。
• 如果业务逻辑不重的情况，gc未必有这么明显的影响。

三.防止客户端性能问题影响结论

• 随时关注client的cpu load mem的情况。
• loading test过程中由于client的性能问题，经常会影响结论。

推荐的办法

• 定时记录各项数据，对比观察。

四.防止客户端线程数过多

• 因为要模拟大量用户，很有可能去启动大量的线程。
• 线程的数量太多后基本都是自己先挂了。

解决

• 用循环来近似模拟多用户。
• 使用scala akka erlang这样的并发模型。

五.其他一些细节

• 同时连接数与同时发数据人数是两个天壤之别的数，前者对系统影响很小，后者的增长才是系统的压力所在。
• 尽可能模拟连接数与发数据人数目标比例。
• 平衡压力尽可能长的时间去压有可能会发现累积性问题。
• 机器越多越方便。