9.1.2.1 2.1.6版本全压力测试

相关改动

机器环境

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

测试方案

两台客户机，每台客户机创建一个独立的topic，每个topic使用120个partition。每个客户端启动240个线程，其中120个线程同步putMessage，剩余120个线程同步的getMessage；putMessage每个包的大小为10K，另外还有一些其他的字段会使长度增加；对于每个读写线程，均采用同步模式，且当上一个请求返回之后，立刻发送下一个请求；

使用2.1.5版本，2.1.6版本，2.1.6改进版本，然后分别按照1 和 2个客户端的情形进行对比测试； 分别使用2.1.5-120，2.1.6-120，2.1.6-new-120，2.1.5-240，2.1.6-240，2.1.6-new-240表示测试的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；

统计数据

数据分析

2.1.5 ~ 2.1.6版本的对比

1. QPS 提升10%以上，Latency 在不同维度均下降30%以上，同时直接读写HDFS Latency也下降30% ~ 50%

上述性能提升主要归结于线程池模型的优化，2.1.5版本的线程为模型：task是按照将其key（TopicAndPartition）取Hash的方式选择线程执行的，这样就会有大量的线程会被唤醒；而在2.1.6版本的线程模型中，会按照任务数据 和 key 的Hash两种方式选择线程，当有线程执行相同key的Task时，直接选择此线程，否则选择等待Task最少的线程，如果线程的等待Task数目相同，则选择线程ID最小的线程；两种方案最大的不同之处在于执行Task的集合，2.1.5基本上为所有的线程，2.1.6方案基本很小部分的线程；当时由于内核调度时时间片的影响，基本相同数量的task，如果分布到更过的线程集合，则由于时间片轮转造成的等待会增加；因此2.1.6会有更有好的结果；例如2.1.6-120中，putMessage的平均延迟为4.1ms，每秒执行的putMessage请求为13884，则理论上需要的线程数目为 13885 / (1000 / 4.1) = 57个线程，平均每台机器需要的线程为14个多一点；注意：上述分析猜测的成本比较多，只是在2.1.6版本测试过线程等待task的数据分布，发现绝大部分线程都等待task为0，但是如果想验证上述猜测，需要做进一步的测试，例如在2.1.5方案中，线程数目对于Latency的影响，2.1.6方案中，task执行线程ID的分布等；

2. 等待时间长尾大大缩减

此项主要由于线程模型优化，2.1.5版本是根据Hash选择线程，会造成即便此线程忙碌仍然要使用此线程的问题，进而长尾较长；问题为新版本在平均值和p75的情况下，等待时间有所增加，但是绝对数据很小，因此可以忽略其影响；

3. 2.1.6版本时间异常

2.1.6版本中，整体PutMessage和GetMessage的延迟，只有25%左右是HdfsWrite 和 HdfsRead的延迟，这个非常不合理，Talos RestServer本身逻辑比较简单，做一些鉴权和认证相关的内容，然后将数据和hdfs进行交互；

2.1.6 ~ 2.1.6-new版本的对比

put/getMessage qps提升10%以上，put/getMessageLatency P75降低80% ~ 150%，同时hdfs时间占到总时间60%以上；对于P99和P999总延迟没有明显的影响，hdfs占去的比例增高

主要由于增大jetty worker线程数目引起的性能提升，主要表现为从执行Auth开始 到真正调用PutMessage/GetMessage为止的时间开销大大缩减，通过分析CPU Busy可以看到，随着线程的提升，cpu busy也得到了一定程度的提升，因此吞吐和latency也降低了；