压力测试详解及JVM调优问题

1.从压力测试说起

压力测试的理解，xxx的性能10w/s，对你有意义么？

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

举个栗子,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只能给你测试结果，不会告诉你性能瓶颈在哪里。

2.压力测试到底要关注什么

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

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

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

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

3.你想要的到底是个什么东西

   tps只是结果，虚拟用户数，线程数，平均响应时长，错误数，90%的平均响应时长，服务器负载，结果准确性尽量用越来越多的点来评估你的服务。

tps：服务处理的吞吐量，每秒响应请求的数量，tps是压力测试最直观的结果，是衡量服务性能的一个结果性指标，一般说压力测试性能值就是tps值。最浅显直白的理解，统计access日志每秒的总数就是那一秒的tps值。

错误数：一般服务压力测试的时候是不允许出现错误的，即错误数:0%,但是复杂条件下，有的服务是允许出错率不超过x%的，看服务而定。

平均响应时长：移动互联网时代，你让一个用户打开app等你1s，用户早就跑了，打开app立刻看见内容是最起码的要求，一般好的app接口相应时间都是毫秒级别的，但是不同的场景不同的要求，我的上一家公司要求平均相应时长在20ms以内。可是上上家公司的算法接口，平均相应时长在100ms，不同的服务不同的要求，你需要找到适合你自己的要求。

90%的平均响应时长：jmeter学来的，表示90%的事务，服务器的响应都维持在某个值附近。比如有三个时间：1秒、5秒、12秒，则平均时间为6秒，而另外一种情况：5秒、6秒、7秒，平均时间也为6秒，显然第二种比第一种要稳定多了。所以，我们在查看平均事务响应时间的时候，先看整体曲线走势，如果整体趋势比较平滑，没有忽上忽下的波动情况，取“Average Time”与“90 Percent Time”都可以，如果整体趋势毫无规律，波动非常大，我们就不用“Average Time”而使用“90 Percent Time”可能更真实些

结果准确性：多线程下访问下结果的正确性。这个在压测的时候往往容易被忽略。这个需要你在压力测试的时候抽查访问接口，查看结果是否正确，曾经碰到过qa测试通过的接口，上线之后发现返回结果不正确，内网回测正确，后来内网压力测试的时候成功复现，是由于使用了不安全的多线程代码导致的，其实压测的时候抽查看一眼，很容易看出来。

线程数：这个指标不在各大压力测试工具监控之内，但是这其实是压力测试非常重要的服务指标。根据经验，好多时候服务崩掉的时候，线程数已经满了，好多时候应用服务器的线程在某个范围之内，服务是最健康的状态，超过某个范围，服务处于不稳定状态，处于有点网络抖动延迟都容易崩溃的临界点，所以熟悉这个值，你就心里清楚你的服务当前在什么状态下。

虚拟用户数(并发线程数)：好多人容易把tps和虚拟用户数搞混，虚拟用户数表示当前正在访问你服务的用户数，就是说压力测试工具启动多少个线程来不停访问你的接口。但是实际上，哪个用户会像疯狗一样疯狂一直不间断的访问的你接口，对用户来说，访问你的接口，点进去看内容，好久不再访问才是常态(专业术语叫思考时间)，可是这个值的大小，严重影响tps的值。那这个值多少合适呢？我知道的有2种做法，一种是求得tps的最大值，在压力测试的时候虚拟用户数不可测，那干脆不管，我就管好我服务的tps吞吐量，服务的吞吐量极限就是我的真实极限。做法就是找一个tps最高时的虚拟用户数，记做压力测试的虚拟用户数指标，当然，这有个严重的问题，做过压力测试的就知道，有的服务虚拟用户很低时tps很高，但是虚拟用户一但稍有提升，性能下降的非常快，怎么弥补这种情况呢，策略是补区间，得到最好tps的虚拟用户之后，在这个虚拟用户数之上加减某个值(例如30)，得到3个压力测试结果，3个压力测试结果的趋势作为服务的性能指标。第二种是估算，当前服务的tps是多少，用压测工具可以得到达到当前tps的并发线程数是多少，但这个值肯定也只是一个估计值而已。

   多说一句，这个值为什么又可以不去管它：其实真正线上流量大的时候经常会有一种现象：服务直接重启撑不起来当前流量，调整前端流量分配(部分nginx摘除重启server等做法),慢慢启动就可以支持起线上流量，再打开所有流量，发现server又可以支持没问题了(ps:所以nginx有一个流量缓增的收费模块就是干这个的)，但是慢慢启动线上流量和一次打过来线上流量，其实在同一时刻虚拟用户数是差不多，斯以为这种现象是因为服务刚启动时流量全打过来时需要创建的可复用复用对象和线程很多，容易造成了服务的不稳定，那么其实压力测试时虚拟用户数重要么？它真的是不可代替的么？其实虚拟用户数只是用来探测服务性能的一个表现的总结而已，服务真正的健康情况其实反映在线程数，响应时长，服务器负载，性能瓶颈点(比如事务或者锁)等等，而虚拟用户数只是这些健康极限情况的表象总结而已。就是说，当压力测试总结的虚拟用户数在某一个范围值tps达到多少，其实内在真正描述的是在这个虚拟用户时，由于线程数是多少，负载是多少，平均相应时长是多少，线程数是多少，gc稳定程度是多少达到了tps值是多少。

4.面试总问的jvm调优到底是要干什么

   请注意，jvm调优，调的是稳定，并不能带给你性能的大幅提升。服务稳定的重要性就不用多说了，保证服务的稳定，gc永远会是Java程序员需要考虑的不稳定因素之一。复杂和高并发下的服务，必须保证每次gc不会出现性能下降，各种性能指标不会出现波动，gc回收规律而且干净，找到合适的jvm设置。详细了解jvm的话请看神书《深入理解java虚拟机》。说些题外话，面试发现，jvm调优很多人都没有经验，有人甚至怀疑这东西真正是否有用，有的公司统一jvm的设置贯穿所有服务。其实只是没碰到生产条件复杂的情况而已，举个简单例子：我曾经的公司，碰到过服务运行超过14h直接死机的问题，头天下午压测，第二天上午服务自动重启了，按照当时习惯，新服务需要压力测试满12h，原则上我的服务通过测试，由于测试环境复杂，所有开发都可以登陆而且脚本很多，qa认为可能是有脚本误杀了，但是当时离上线deadline时间还早，于是决定再压力一次，成功复现，最后查看jvm发现每次fullgc之后o区总是会多一点，jmap打印内存栈发现char对象使用逐渐增大，最后撑满内存， 最后定位到调用JNI发生内存泄露，解决了这个问题。这只是简单的一次，在那家公司，由于服务偏算法而且流量很高，碰到过很多这种问题。还有一次，压力测试loadrunner图像显示每隔一段时间的点上响应时间立刻下降，过2s又恢复正常，规律性很强，通过jstat发现频繁生成大对象直接进入老年代，老年代很快撑大触发full gc回收，回收时间过长造成服务暂停明显，立刻反应到压测的响应上。解决的办法是调大年轻代，让大对象可以在年轻代触发yong gc，调整大对象在年轻代的回收频次，尽可能保证大对象在年轻代回收，减小老年代缩短回收时间，服务果然稳定下来。当时这么调整下来会有一点性能损失，基本可以忽略不计，但是提升了服务的稳定性，这才是这次jvm调优最重要的。

5.常用的压力测试工具及命令

loadrunner，jmeter，自写jar包，tcpcopy等。

   压力工具，大同小异，用什么都行，tcpcopy是拷贝线上流量，对于已有接口和服务做压力测试是个神器，jmeter和loadrunner是压力测试工具，loandrunner压测结果更详细可视化不过笨重收费而且需要很多客户机，jmeter相对是平民版的loadrunner，胜在免费。之前也有由于数据需要实时从数据库查询，自己写http的client，就需要辅助一些shell和awk命令统计相应指标。

   jmap，jstack，jstat，详细的讲解推荐《深入理解java虚拟机》，其实不神秘但是特别实用，jstat查看内存回收概况，实时查看各个分区的分配回收情况，jmap查看内存栈，查看内存中对象占用大小，jstack查看线程栈，死锁，性能瓶颈，某个线程使用cpu过高导致服务整体慢等都可以通过在这些命令辅助Linux命令看出来。

top，vmstat,sar,dstat，traceroute，ping，nc，netstat，tcpdump，ss等等具体请百度。

   你的服务是跑在linux系统上的,是依赖第三方服务出问题了？是受别的服务影响还是自己利用资源过高？是网络抖动了？是网卡满了么？是cpu性能不够么？是写入磁盘瓶颈了？内核数据交换频繁？负载变高了？都需要linux命令才能看出来。

6.性能诊断到底难在哪里？

   收到服务报警了，怎么办？打印的log日志都是连接不上memcache，难道是memcache的问题，手动客户端连接memcache没问题，难道是网络的问题，测试网络延迟很低，那到底怎么了？

其实服务类似于人体，有的人感冒的时候鼻子通气嗓子疼，有的人头疼，有的人流清涕，有的人流黄涕，对症下药要治标治本。没有什么统一的答案，这就体现了经验的重要性。举个栗子：某天晚上突然收到报警，登陆发现服务还正常返回，暂时没有报错，但是负载明显升高，resin线程数飙升到1000多(正常情况下该服务高峰期线程数500-700)，cpu使用率偏高，排查:1.访问量激增？统计发现并没有。2.网络状况异常？通过访问服务器发现也没有，稍微慢些是因为负载稍高。3.程序有瓶颈?打印内存栈线程栈都没发现4.受其他同宿主服务影响？查看监控发现并没有。仔细观察发现流量稍有波动但是不明显。为什么负载高呢？最后排查发现是前端nginx带宽满了，带宽拥堵造成代理的后端服务无法及时返回数据，后端服务的句柄数拥堵造成服务器负载升高，服务器负载升高又使线程数和cpu利用率升高，造成服务的个别访问响应时长过长，触发报警。再严重些估计就会造成连接memcache超时，log打出连接memcache错误的日志。蝴蝶效应而已。想要快速抓住重点，其实跟医生一样，就需要你对服务足够了解，平时多关心服务状态而且经验真的很重要。

7.到底是加机器还是优化服务？

   成本，加机器是一种成本，优化服务也是一种成本，很有可能你的服务很多依赖第三方，推动他们符合你的要求也是一种沟通成本，很多时候，老板的思路永远在于成本，如果他认为服务有很大的优化空间，那你找他加机器他多半是不会同意的，所以这种要资源的事情，请考虑成本，也有一个问题，大公司往往会哭的才有奶吃，这也很现实，反正归根到底，对于我们这些搞服务端的来说，成就感不就应该是把硬件服务器资源压榨到底么？