Talos测试场景及结果


相关改动

commit Revision change
c0fc9f8cac7d923d1a06a7235d21e54919d3d42a D66598 增加优先级队列支持
ee3d9d614fd36e5ea07460228c670f40e434dbf4 D66823 修改转发模型,到每台机器都使用单独线程池和thrift Clinet
5e068156aefda275c926b90c50f8df0cfebec7f9 D67054 在读写请求增加过期时间戳,当超时时候直接从talos的队列中返回
4cde032af7c9d3f698fc2072cf37dfa38adc2932 D67338 当RestServer处于DelayRemoved状态时,直接返回PartitionNotServe

机器环境

  • 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;

统计数据

MeanLetency

P75Latency

P99Latency

P999Latency

CPUBusy

数据分析

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在线程池排队时间的长尾现象极大的改善,符合之间设计的预期;

results matching ""

    No results matching ""