性能测试流程（重点）

需求调研-设计场景-制造脚本-准备环境 -了解配置-提出优化建议

压测咱们都应该知道哪些：

1.压测场景，用户行为

2.压测机服务配置：

   核数，可用内存，网络带宽（上传和下载速率=网络带宽/8），内网压测（没有带宽限制，就至关于与在一个屋子里干活没有门的限制），外网压测（有带宽限制）

3.应用服务器，数据库服务：

好比放了mq的服务器那他CPU就可能降低的慢，若是mq的服务器CPU太高或者缓存太高那就可能说明mq里面放的东西太多了，减小一些没必要要的应用，好比CPU太高，能够考虑调整内核参数，服务器下载宽带太小，能够加大宽带，从原来的20kb加到50kb。

重点：若是所放的特殊应用的那台服务器挂掉，那么进入这个这个应用的业务也会瘫痪，这已经不是负载的事情了，会致使功能缺失业务瘫痪，好比：订单进入mq，可是mq对应的这台服务器挂掉了，那么订单处理这个业务就算缺失了，因此必定要清楚是怎么负载的，程序在什么状况下，什么时间节点进入那台服务器，提出服务器分发建议。

4.了解每一个应用：

　　每一个应用都作了什么？，他们作事的特色是什么？，他们作事所消耗那些资源？（如：比较消耗内存，那些比较消耗cpu，那些比较吃宽带）

5.分析指标：

　　CPU，内存，等在拐点变化时，服务器都在干什么？

　　CPU使用率到达多少时是最佳状态/最糟糕的状态，缓存，IO等达到多少时是最佳状态/最糟糕状态

　　聚合报告中：吞吐量（TPS），以及一些响应时间，理解个个指标之间的关系。

6.优化建议：

CPU太高：调整内核参数

内存太高：加大内存，调整任务分发比例，调小

Received KB/sec：  达到带宽极限，加宽网络宽带，提升：上传和下载速率=网络宽带/8

服务部署应用结构：好比放了mq的服务器那他CPU就可能降低的慢，若是mq的服务器CPU太高或者缓存太高那就可能说明mq里面放的东西太多了，减小一些没必要要的应用

　　重点：若是所放的特殊应用的那台服务器挂掉，那么进入这个这个应用的业务也会瘫痪，这已经不是负载的事情了，会致使功能缺失业务瘫痪，好比：订单进入mq，可是mq对应的这台服务器挂掉了，那么订单处理这个业务就算缺失了，因此必定要清楚是怎么负载的，程序在什么状况下，什么时间节点进入那台服务器，提出服务器分发建议。

慢sql查询：优化sql，优化数据库。

代码冗余：优化程序。

7.其实咱们还能够针对这上面的每一种指标均可以设计一种场景来看他们的瓶颈在哪里

 

1、TPS：Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。（业务TPS = CAPS × 每一个呼叫平均TPS）

TPS是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求而后服务器作出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

通常的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统总体处理能力取决于处理能力最低模块的TPS值。

 

2、QPS：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，做为域名系统服务器的机器的性能常常用每秒查询率来衡量。

对应fetches/sec，即每秒的响应请求数，也便是最大吞吐能力。

下面就说说压测中为何TPS上不去的缘由：

一、网络带宽

在压力测试中，有时候要模拟大量的用户请求，若是单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会形成网络资源竞争，间接致使服务端接收到的请求数达不到服务端的处理能力上限。

二、链接池

可用的链接数太少，形成请求等待。链接池通常分为服务器链接池（好比Tomcat）和数据库链接池（或者理解为最大容许链接数也行）。

（关于链接池的具体内容，可参考以前的博客：性能测试：链接池和线程）

三、垃圾回收机制

从常见的应用服务器来讲，好比Tomcat，由于java的的堆栈内存是动态分配，具体的回收机制是基于算法，若是新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS

也是有必定影响的，由于垃圾回收其自己就会占用必定的资源。

四、数据库配置

高并发状况下，若是请求数据须要写入数据库，且须要写入多个表的时候，若是数据库的最大链接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，

就会致使数据库事务处理过慢，影响到TPS。

五、通讯链接机制

串行、并行、长链接、管道链接等，不一样的链接状况，也间接的会对TPS形成影响。

（关于协议的链接，可参考以前的博客：HTTP协议进阶：链接管理）

六、硬件资源

包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。

七、压力机

好比jmeter，单机负载能力有限，若是须要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就须要进行分布式压测来解决其单机负载的问题）。

八、压测脚本

仍是以jemter举个例子，以前工做中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，致使线程不足。

提到这个缘由，想表达意思是：有时候测试脚本参数配置等缘由，也会影响测试结果。

九、业务逻辑

业务解耦度较低，较为复杂，整个事务处理线被拉长致使的问题。

十、系统架构

好比是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过时等，都会影响到测试结果。

 

PS：性能瓶颈分析不能单从局部分析，要综合起来，多维度分析问题缘由。上面列出的几点，可能有描述不当或者遗漏的，仅供参考。。。

若是有不许确的，请评论指正，谢谢！