9.1.2.2 2.1.6版本模拟真实流量测试

相关改动

机器环境

• 2台客户机，4台Talos机器，4台Hdfs，4台HBase，Talos与Hdfs/HBase混布，机型均为2U；
• 读写同步，每个partition对应一个线程；

测试方案

两台客户机，每台客户机创建一个独立的topic，每个topic使用1200个partition。每个客户端启动2400个线程，其中1200个线程同步putMessage，剩余1200个线程同步的getMessage；putMessage每个包的大小为70K，另外还有一些其他的字段会使长度增加；对于每个线程，一秒钟发送2.1个数据包，因此单个客户端可以模拟每秒2500个PutMessage请求；对于GetMessage也是每秒2500个请求，用于目前c3srv-talos集群的实际流量；同时启动两个客户机时用于模拟流量翻倍的情形，也即之前c3srv-talos集群当台机器宕机故障的时候相关场景；

使用2.1.5版本，2.1.6版本，2.1.6改进版本，然后分别按照1 和 2个客户端的情形进行对比测试； 分别使用2.1.5-1200，2.1.6-1200，2.1.6-new-1200，2.1.5-2400，2.1.6-2400，2.1.6-new-2400表示测试的case；

相关参数

2.1.5：putMessage，getMessage，transferPutMessage，TransferGetMessage线程均为200，到单台机器的client数据上限为100；Jetty acceptor线程为10，worker线程为100

2.1.6：putMessage，getMessage线程为200，transferPutMessage，transferGetMessage线程为50，由于有4台机器，因此每个进程共有150个线程，到单台机器client上线为50；Jetty acceptor线程为10，worker线程为100

2.1.6-new：和2.1.6完全一致，除去Jetty worker线程为300；

统计数据

数据分析

1200 partition的情况

• 对于延迟：2.1.6 < 2.1.6-new < 2.1.5

• 对于队列等待时间：2.1.6 < 2.1.6-new << 2.1.5

对于上述两个改进，和情况1类似，只是延迟只有比较微弱的提升，但是对于队列等待时间在p99和p999两个维度有非常明显的提升；主要为集群压力较小所致；

对于2.1.6-new 性能差于2.1.6，主要是集群压力不高，过多的线程数目会造成一定的损耗；

2400 partition的情况

• 对于延迟：2.1.6 < 2.1.6-new << 2.1.5

• 对于队列等待时间：2.1.6 < 2.1.6-new << 2.1.5

特别说明：

• 2.1.5-2400-2：在进行2.1.5版本测试时，一共持续了70分钟，对于前35分钟，各种统计数据非常巨大，客户端超时非常严重，即集群处于不可用的状态；在后35分钟，情况有好转，但是相关Latency仍然非常差；因此个别统计想在图中显示为“-20”，说明此值的原始值非常大，为了图片展示，因此标注为负数；

• 对于之前测试中出现的hdfs 操作占整个读写操作比例不高的问题，在此次测试中未出现；

总结

新版本在压力增加100%的情况下，可以很好的完成预定目标，即没有出现服务不可用的情况；同时由于优化了线程队列模型，进而使得各个task在线程池排队时间的长尾现象极大的改善，符合之间设计的预期；