需求调研-设计场景-制造脚本-准备环境 -了解配置-提出优化建议
压测我们都应该知道哪些：
1.压测场景，用户行为
2.压测机服务配置：
核数，可用内存，网络带宽（上传和下载速率=网络带宽/8），内网压测（没有带宽限制，就相当于与在一个屋子里干活没有门的限制），外网压测（有带宽限制）
3.应用服务器，数据库服务：
比如放了mq的服务器那他CPU就可能下降的慢，如果mq的服务器CPU过高或者缓存过高那就可能说明mq里面放的东西太多了，减少一些不必要的应用，比如CPU过高，可以考虑调整内核参数，服务器下载宽带过小，可以加大宽带，从原来的20kb加到50kb。
重点：如果所放的特殊应用的那台服务器挂掉，那么进入这个这个应用的业务也会瘫痪，这已经不是负载的事情了，会导致功能缺失业务瘫痪，比如：订单进入mq，但是mq对应的这台服务器挂掉了，那么订单处理这个业务就算缺失了，所以一定要清楚是怎么负载的，程序在什么情况下，什么时间节点进入那台服务器，提出服务器分发建议。
4.了解每个应用：
每个应用都做了什么？，他们做事的特点是什么？，他们做事所消耗那些资源？（如：比较消耗内存，那些比较消耗cpu，那些比较吃宽带）
接口之间的调用链路关系：如mq消费链路图，消费方式。
5.分析指标：
CPU，内存，等在拐点变化时，服务器都在干什么？
CPU使用率到达多少时是最佳状态/最糟糕的状态，缓存，IO等达到多少时是最佳状态/最糟糕状态
聚合报告中：吞吐量（TPS），以及一些响应时间，理解个个指标之间的关系。
6.优化建议：
CPU过高：调整内核参数
内存过高：加大内存，调整任务分发比例，调小
Received KB/sec： 达到带宽极限，加宽网络宽带，提高：上传和下载速率=网络宽带/8
服务部署应用结构：比如放了mq的服务器那他CPU就可能下降的慢，如果mq的服务器CPU过高或者缓存过高那就可能说明mq里面放的东西太多了，减少一些不必要的应用
重点：如果所放的特殊应用的那台服务器挂掉，那么进入这个这个应用的业务也会瘫痪，这已经不是负载的事情了，会导致功能缺失业务瘫痪，比如：订单进入mq，但是mq对应的这台服务器挂掉了，那么订单处理这个业务就算缺失了，所以一定要清楚是怎么负载的，程序在什么情况下，什么时间节点进入那台服务器，提出服务器分发建议。
慢sql查询：优化sql，优化数据库。
代码冗余：优化程序。
7.其实我们还可以针对这上面的每一种指标都可以设计一种场景来看他们的瓶颈在哪里
一、TPS：Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。（业务TPS = CAPS × 每个呼叫平均TPS）
TPS是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。
二、QPS：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
下面就说说压测中为什么TPS上不去的原因：
1、网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
2、连接池
可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。
（关于连接池的具体内容，可参考之前的博客：性能测试：连接池和线程）
3、垃圾回收机制
从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS
也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。
4、数据库配置
高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，
就会导致数据库事务处理过慢，影响到TPS。
5、通信连接机制
串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。
（关于协议的连接，可参考之前的博客：HTTP协议进阶：连接管理）
6、硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。
7、压力机
比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。
8、压测脚本
还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。
提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。
9、业务逻辑
业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。
10、系统架构
比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。
PS：性能瓶颈分析不能单从局部分析，要综合起来，多维度分析问题原因。上面列出的几点，可能有描述不当或者遗漏的，仅供参考。。。
如果有不准确的，请评论指正，谢谢！