曾经参加过一次双十一压测，这里只是记录一下性能压测总结
机器cpu 利用率高是好事，一般cpu使用率在70%左右比较合理。老大说的，待验证。
单接口压测，探测峰值和最大并发数。
并发依次递增，qps线应该是上阳并走出一个峰值，该峰值为最大qps，继续增加并发，看90%相应时间，如果相应时间在某个合理接受范围内，找到最大并发数。当然好多时候并非让你如愿，也许程序有问题，一开始qps就是上不去，相应时间很长，那就得查查了。
这里就说到一点，qps达到多少为合格，相应时间为多少算能接受。
先说qps= req/sec = 请求数/秒。首先这个数据可以根据当时活动业务需求进行估算，而非固定值，下面举个HLJ双十一例子进行说明，如当时双十一业务指标就是店铺充值卡业务目标是七千万，如果按照以往经验，压力都在前两小时，7000*10000 /2*60*60 =7000*10000/7200 = 10000，每秒要完成10000的金额 ,当时充值面额有100，300，500，1000，5000，平均下来一单应该算800的客单价，计算下来充值卡下单接口为10000/800=13，这样计算下来下单接口qps至少要达到这个数据，再根据这个固定接口计算出其他相关qps支撑数据，如店铺详情浏览数量等等。此处数据有可能不准，但思路是这样的。用确定去衡量不确定。第二个办法就是参考以往历史，个人感觉第一种方法最优，毕竟每次活动力度不同，qps 要求肯定不同。
如果某个接口程序上无法做到优化，qps不高且不满足要求时怎么办？
如果单点（数据库，redis，带宽）不是瓶颈点，试试水平扩展（即增加几台服务）看看效果。
压测过程中需要关注的点
（1）、压测机cpu使用率，load ，带宽（当时我们网络带宽最大就只支持一个G）
（2）、数据库机器cpu使用率、带宽。
（3）、redis服务器cpu使用率、带宽（当时有使用redis做缓存）。
（4）、应用服务器错误日志
（5）、对于单点都没问题，且应用服务器cpu使用不高，qps上不去，得用jvisualvm 查看一下到底是那里最耗费时间。对于耗时特别长的可以进行分析定位。(使用jvisualvm可以进行远程服务器监控，但是需要添加一点配置，在tomcat bin 下catalina.sh文件的JAVA_OPTS变量加上JAVA_OPTS='-Djava.rmi.server.hostname=10.0.10.17 -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false' )，在jvisualvm使用远程链接10.0.10.17 链接8999端口即可以啦。
(6)、使用jvisualvm监控cpu时，如果发现很多borrowobject 代表连接池不够用，得想想是改大连接池呢，还是水平扩展呢？
（7）、使用jstack 打印线程栈(如jstack 34982 >unicorn0.text)，看看大部分线程都在干嘛？（出现wait得时候）（具体参看20171028笔记，老大分析可牛了）
（8）、还可以查看gc情况啦。
我还是先查了一下几个指标代表的意思：
吞吐量（）、QPS、并发数、响应时间（RT）
0. 响应时间(RT)
响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。
1. 吞吐量(Throughput)
吞吐量是指系统在单位时间内处理请求的数量。
对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多步骤难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。
2. QPS每秒查询率(Query Per Second)
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
从以上概念来看吞吐量和响应时间是衡量系统性能的重要指标，QPS虽然和吞吐量的计量单位不同，但应该是成正比的，任何一个指标都可以含量服务器的并行处理能力。当然Throughput更关心数据量，QPS更关心处理笔数。
QPS提升带来什么？QPS提升说明单台服务器处理能力提升，如果QPS提升1倍，服务器资源减少1半，或者说服务器不变可以支撑2倍的请求量。
如何提升QPS？
1）减少CPU的使用时间（哪些代码会消耗CPU：循环、字符串拼接查找替换、编码解码、序列化反序列化、压缩）
2）增加CPU的数量
3）减少同步锁
（如果CPU不能被压到85%以上，并且此时的QPS已经达到了峰值，则说明另有瓶颈，接下去关注内存）
RT提升带来什么？
响应速度提升说明单次请求的处理速度提升，用户感觉任务处理速度更快，系统反应速度更快。当然在处理能力不变的情况下，RT的提升必然会提升QPS。
如何提升RT？
1）减少I/O的响应时间
2）减少I/O的调用次数
3）减少CPU使用时间（当然在I/O占大头的应用里，这方面优化效果肯定不明显）
总结提取上面有意思的话语单独贴出：
a、如果CPU不能被压到85%以上，并且此时的QPS已经达到了峰值，则说明另有瓶颈，接下去关注内存）
几个点，cpu使用率85% qps到达峰值,几个意思？
（1）cpu始终上不去
（2）qps一直没出现拐点。