记一次性能问题思考

因为从业三年，还未真正接触过性能测试，面试被问到

TPS(每秒事务数）上不去的原因，百度答案以及找到参考

什么是tps呢？

(transaction per second) 每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量，一般以request/second为单位。

原因参考大神提供的有以下几点 

1、网络带宽

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

2、连接池

可用的的连接数太少，造成请求等待，连接池一般分为服务器连接池（如tomcat）和数据库连接池（可理解为最大允许连接数）。

3、垃圾回收机制

从常见的应用服务器来说，比如tomcat，因为java的堆栈内存是动态分配，具体回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC,老年代的full GC也回收频繁，那么对tps也是有一定影响的，因为垃圾回收机制本身就会占用一定的资源。

4、数据库配置

高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的sql没有索引没有绑定变量，或者没有主从分离，读写分离就会导致数据库事务处理过慢，影响到tps。

5、通信连接机制

串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对tps造成影响。

6、硬件资源

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

7、压力机

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

8、压测脚本

还是以jmeter举个例子，之前工作同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响结果。

9、业务逻辑

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

10、系统架构

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

jmeter性能测试重要指标，以及性能结果的分析

资源指标：(cpu，内存，IO ,带宽）

系统指标（并发用户数，响应时间，事务成功率，超时错误率）

查看结果树的各项指标

Lable:每个Jmeter的element(例如HTTP request)都有一个name属性，这里显示就是name属性的值

sample:表示这次测试一共发出了多少次请求，如果模拟10用户，每个用户迭代10次，那么这里显示100

average:平均响应时间-默认情况下单个request的平均时间，当使用了transation controller,也可以以transaction为单位显示平均响应时间

median:50%用户响应时间

90%line:90%用户的响应时间

min:最小响应时间

max:最大响应时间

error%:本次测试出现错误的请求数量/请求总数

trougput:吞吐量-默认情况下表示每秒完成的的请求数量（request per second）,当使用transction controller时，也可以表示类型loadrunner的transaction per second数

KB/Sec:每秒从服务器端接收的数量，相当于loadrunner的throughputs/Sec