标签：Performance

redis analyst (6)- simple performance test for mini cluster

其实测试这种分布式系统意义不是非常大，因为通过监控metric发现性能瓶时，直接增加节点即可，在很大范围内，节点数不是非常多的话，基本上处理能力呈线形增长，直接引用源作者的话：

“High performance and linear scalability up to 1000 nodes. There are no proxies, asynchronous replication is used, and no merge operations are performed on values.”

但是为什么要做一个简单的性能测试，因为第一次部署redis cluster，到底部署什么样的规模才能满足需求是无法回避的问题。所以还是简单测试下，为什么称为简单测试，因为实际环境中的软硬件配置、实际应用操作的读写比例、读写内容大小、读写波动范围、读写的机器数、线程数等实际场景，远不是本地可以简单真实模拟的。所以这里只是简单测试下(关注点在速度)，以有个感性的认识，以回答部署需要什么样的规模等问题。


127.0.0.1:7001>cluster nodes
87903653548352f6c3fdc0fa1ad9fc68de147fcd 10.224.2.142:7001 myself,slave 798f74b21c15120517d44bacfc7b5319b484244b 0 0 2 connected
3892d1dfa68d9976ce44b19e532d9c0e80a0357d 10.224.2.141:7001 slave b2b98976dfbc9f85bf714b385e508b3441c51338 0 1517983027812 17 connected
798f74b21c15120517d44bacfc7b5319b484244b 10.224.2.145:7001 master - 0 1517983028313 5 connected 5461-10922
b2b98976dfbc9f85bf714b385e508b3441c51338 10.224.2.144:7001 master - 0 1517983027813 17 connected 10923-16383
b71b412857c43e05a32a796fbc0de2e7d667cb67 10.224.2.143:7001 slave 912a1efa1f4085b4b7333706e546f64d16580761 0 1517983026306 6 connected
912a1efa1f4085b4b7333706e546f64d16580761 10.224.2.146:7001 master - 0 1517983026809 6 connected 0-5460

 

Redis Cluster  Node number Mini Redis cluster (6 nodes:  3*2 )
 Configure  Hardware  Cpu: 2 * Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz

Memory:  4G(3924392)
 Software  #disable save cache content to disk
save “”
appendonly no# memory limit
maxmemory 1G
maxmemory-policy allkeys-lru		  make sure never reach max memroy
 Test Machine   Node number  15
 Configure Hardware configures Cpu: 2 * Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz

Memory:  8G(8180636)
Software configures Jedis connection pool :

DEFAULT_MAX_TOTAL = 8
 Test method  Operation  write Test1: 10(machine) * 50(thread per machine) * 20K(write operation)= 10000K

Test2: 15(machine) * 50(thread per machine) * 20K(write operation)= 15000K

  String set(final String key, final String value)(1) key size: about 30

(2) value: size:

about 30
read  Test1: 10(machine) * 50(thread per machine) * 20K( read operation)= 10000K. data base existed 10000K records

Test2: 15(machine) * 50(thread per machine) * 20K( read operation)= 15000K,  data base exixted 15000K records

 String get(final String key)

(1) no hit

(2) key size:about 30
  Test result  OPS  Read  100K
 Write  50K
 Success Ratio Read  100%
 Write  100%

通过下图可知：测试中的key分布比较均匀，所有的压力平坦到3个master中，虽然测试的总tps很高，但是由于三个人干活，导致每个节点其实也还好，凸显分布式优点。

operation per second

测试结论： redis cluster的最小集（3*2），单纯考虑速度，不考虑容量限制，已经能支持很高TPS的需求了，另外需要注意的事，这是理想的测试，所以实际评估中仅供参考。

题外： 将读写测试1:1混合，会怎样，将两种测试同时并发执行，还能达到10万/S读，5万每S写么？测试结果如下：

总的OPS，只能达到45Kops, 然后读写吞吐量基本差不多1:1。这种数据比单纯只测一种更具有实际参考价值。

concurrent write/read

Performance Tuning-how to do performance test?

之前也零散的做过性能测试，但是也是糊里糊涂（当时将性能测试简单理解为启动一批线程发请求给服务器，然后记录CPU和内存等关键指标，看看是否存在问题）。最近接手两种nio类型服务器的测试（jetty+resteasy构建的http服务，和apache mina构建的tcp服务）的性能测试，所以系统研究了下性能测试到底要关注什么？

 

性能测试的二个前提

 

（1）有没有做性能测试的必要？

基于最初的架构原型没有变化？如果没有变化且已知修改的代码不会影响性能，是否需要做重复的性能测试？

如果已预测性能瓶颈所在，何必先测后改，不如先改后测？

假设性能可能存在问题，短期内是否有充足时间去完善？

如果基于以上三种分析，我们仍认为有必要做性能测试，再去开展。

（2）测试对象的硬件配置和环境配置是什么样的？

这是进行性能测试的前提之一，假设服务部署在4核CPU，而性能测试是基于2核CPU做的，那测试得出的benchmart数据说服力不高，因为硬件配置不同。

所以在进行性能测试之前一定要和产线环境的机器配置完全或尽可能相同。

备注：实际操作时，也可以选用低配置的做一个预测试更容易暴露瓶颈，但是在最终测试时，还是要贴近实际。

 

性能测试的四个关注点

（1）吞吐量Throughput ：单位时间内处理的请求总数，一般秒为单位。

（2）延时Latency： 系统对单个请求的响应，一般毫秒为单位。

（3）资源使用率：包含CPU,内存，IO, 网络等关键资源。

（4）请求失败率：请求失败的比例是多少。

在收集整理完在不同TPS的情况下，后三者的数据情况，才能为系统定一个合适的TPS提供标准，比如在100TPS的时候，延时超标了，或者成功率低或者资源使用率过高，那么TPS就不能选择100TPS。系统的处理能力是综合这四点的一个结论。

 

性能测试的七个要点

（1）延时不能仅仅看平均延时：性能测试中，关注延时是必然的，但是不能仅仅在意平均延时，而忽略各种延时值的分布，假想一个系统的平均延时是100ms, 确实为我们所接收，但是通过数据的分析，我们获知50%的请求是10ms以下，而50%的请求在190ms，这个时候，单纯认为延时就是100ms,就是为客户所接收就不合理。

（2）请求失败率是必须要考量的：如果单纯看延时，在某个TPS时，延时或许已经满足了需求，但是在这个TPS时，请求已经有少许失败，那么这种失败率一定要记录下来作为参考，否则单纯的记录TPS和延时就说系统可以胜任工作是不合理的，同时大多系统都允许一定的失败率，所以失败率一定要记录在案以提供参考。

（3）性能测试要有一定的持续时间：如果测试仅仅做了几秒或者几分钟，就得出相关的数据然后推断系统性能没问题是不科学的。假设一个系统是多线程接受+单线程处理，那么在初期性能可能会很好，而随着多线程接受的请求数一旦累加超过单线程的处理能力，会导致响应时间约来越长。所以说性能测试一定要注意是否持续了充足的时间。当然很多性能问题，最好先预估下性能瓶颈，否则持续的时间不是特别长都无法复现问题，而持续时间特别长对测试来说已变得不切实际。

（4）TPS的控制是否准确：在实际测试中，我们模拟一定的TPS效果，但是一定要核算下是否真的做到了某个TPS的效果。比如1台机器启动300个线程，每个线程模拟1秒内发5个请求，据此推断TPS是1500TPS，这样是否科学，还需要实际复查，因为对于单个机器CPU处理能力有限，对于这个业务请求并发度真的有那么高么？

（5）计算的时延是包含发出+接受，还是仅仅是处理时间：这点很重要，如果仅仅是记录处理时间，那么不能完全说一个请求的时延是多少，因为可能接受到请求会排队，之前也有建立连接等过程，所以一定要区分自己所记录的时延是从什么开始到什么时候结束。

 （6）性能测试方式对系统本身的影响：例如对于或许延时，我们可能使用profiler系统的方式进行，或者直接加一些log来计算，这些都会对系统本身产生一定的影响，一定要意识到这种影响，并且在发现影响过大时规避这些影响带来的错误结果。

 （7）是否真实反映了应用场景：大多时候我们会从不同角度简单化测试点，例如单纯并发多少写，单纯并发多少读，但实际中，我们还需要考虑实际的真实场景：例如读写都会有且比例不同。另外对于一个系统可能提供多种类型丰富的应用：例如不仅提供http也提供tcp服务，如果不考虑彼此，单纯的测试某一项服务只能反映只提供这项服务时的系统性能，系统的真实性能应该是综合同时提供服务的综合性能。

 

 性能测试工具的设计：

包括3个阶段：

prepare, stress, analyst.

 

性能测试的四个结论

（1）系统的TPS是多少？ 

（2）系统的并发度是多少？

例如假设我们算出1个请求的处理时间是100ms, 所以原则上我们知道TPS是10TPS,但是实际测算我们的TPS是100.那么可知系统肯定是多线程模型，并发度达到了10.如果系统的TPS就是10,那么明显是单线程模型

（3）系统瓶颈所在？

在拿到系统时延，资源使用率后，我们可以profiler系统找到系统的瓶颈所在。以有针对性的去解决。

（4）一个请求完成需要多长时间？

在不同的并发度前提下，单个请求的完成延时是多少？

 

性能测试是涉及知识领域比较多比较深入的话题，上面简单分享了下自己的体会，多有不足，还需要在日后的工作中慢慢体会。