压力测试你应该知道的几个道理

没有那家卖瓜的会说自己家的不甜，同样，没有哪个开源项目愿意告诉你在对它条件最苛刻的时候压力情况是多少，一般官网号称给你看的性能指标都是在最理想环境下的，毫无参考意义。

举个栗子,redis官网压测的例子，256字节的读速度11w/s,写速度8.1w/s,都知道redis优点是多变的数据结构，string、List、hash、set、sortset，实际工作稍微复杂的环境往往都是各种结构混合使用，字符串长度各异，你需要的是真正在你的工作环境下，即：你混合使用的数据结构下，你的访问压力下，你的字符串长度下redis的x响应性能。这个值往往跟官方公布的差异很大。我的经验，我们是视频行业，相对字符串长度较长，在压缩序列化之后，主要使用String和List，性能在访问client=200-400左右，qps相应能到5w，超过这个client值，qps下降而且服务器负载上扬，容易引起服务器雪崩效应，这个5w，才是真正基于我们业务使用下redis的性能瓶颈。

我这个服务压力2000tps,你觉得很牛逼？

看着很牛逼对不对，好像tps值越高显得能力越强一样，其实很可笑，如果性能好只是比这个，那写一个1+1=2的程序估计是无敌了吧。具体问题要具体分析，你牛逼你要说明你牛逼在哪里，在什么条件下，什么样子的背景，才能说你的tps是多少，这样才有意义。

反正线上没出现过问题,我们撑得住，你确定？

线上没出现过问题，不代表流量不会增加，流量不会增加不代表业务不会复杂，业务复杂性能下降是很有可能的，没有压力测试做保证，出问题就是大问题。

压力测试都是qa在做，有问题会反馈给我，你的服务极限到底在哪里？

你应该关注一下qa是怎么做压力测试工具的，无论从服务的角度还是从个人发展的角度。qa只能给你测试结果，不会告诉你性能瓶颈在哪里。

压力测试到底要关注什么

压测不是玩笑，你的4个9的指标呢

好的服务都会有一项指标，叫4个9，即99.99%得服务可靠性。这是衡量一个服务是否优秀的普世标准，压力测试的好坏最直观的影响4个9的保障。压力测试就是用来确保服务的稳定，给出服务稳定极限条件。稳定指的是服务负载，cpu利用率，接口的响应时长，网络的延迟，结果准确性等等都在你的标准之内。而这些指标又相互影响。

条件，用尽量多的已知去推测未知，模拟仿真，你要做的预测未来

硬件条件:服务器cpu核数、内存大小、网络条件、同宿主机下其他服务影响，软件条件:虚拟访问用户数、gc的稳定程度，响应时长要求，第三方依赖的可用程度、jdk的不同版本等都会严重影响压力测试的结果，软件测试工具造成你的压测结果上线之后达不到逾期。如果这些条件不注意，很可能你压测时按照达标条件tps=1000，其实线上tps才500的时候，服务已经崩溃了。压测的时候，最好保障压测环境与线上一致。你的结果才更有意义。