一、网络带宽

压力测试时，要模拟大量用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端处理能力上限。
个人理解：

1）测试时一般是测试环境、预生产环境、生产环境；

其中测试环境一般为内网，可以最大限度屏蔽掉网络带来的影响，这才能更好的体现发现其他方面的性能问题；
但是内网也是有网络传输的，如果内网网速太慢，也会非常影响性能测试结果，如果2次性能测试环境一模一样但结果大不相同，有时候可能是网速的锅哦，所以性能测试时也需要监控网速；（实际测试时并未监控网速，所以网速是必须监控的吗？）

2）如果在公司内对外网的生产环境测试，那么就得特别考虑网络问题了；

此时还得考虑程序本身特点，是否传输的数据包必然大，如上传多个照片、文件等；这时候很可能网络已经成为瓶颈了，测试结果不会准确；怎么解决（解决方式仅为个人想法未验证）？在生产环境搭建性能测试环境，避免网络影响；或者将网络影响纳入考核范围，如果网络慢了就改善网络（网络这块不懂，这么说不一定对）

二、连接池

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

三、垃圾回收机制

从常见的应用服务器来说，比如tomcat，如果堆内存设置比较小，就会造成新生代的Eden区频繁的进行Young GC，老年代的Full GC也回收较频繁，那么对TPS也是有一定影响的，因为垃圾回收时通常会暂停所有线程的工作。

四、数据库

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

个人理解：
1）索引：慢sql很多时候是由于字段未加索引造成的；但是索引也不能随意加或多多加，一般得根据性能测试结果分析后再增加；
2）table_open_cache需要设置为合理值，否则会导致数据库查询慢（目前的table_open_cache是默认的2000，对于一般数据库系统可能没什么，但对于大量业务库共存的情况，可能会有性能问题）；
比较适合的值：（引用文章：https://blog.51cto.com/13120271/2130558）
Open_tables / Opened_tables >= 0.85
Open_tables / table_open_cache <= 0.95
3）数据量：当数据量比较大，如达到上万条，一些sql语句会变慢；

五、硬件资源

包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I\O、页交换等）
1、CPU
2、内存
3、磁盘IO（具体分析见本人另一篇文章：https://blog.csdn.net/xiaona0523/article/details/107860633）
1）top
2）iostat

六、压力机

如Jmeter、Loadrunner，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS，此时需要进行分布式压测来解决其单机负载的问题。
个人理解：
如Jmeter，GUI模式下也会影响性能，尤其是开着一些监听器的情况，可以考虑使用非GUI模式；

七、业务逻辑

业务解耦度较低，较为复杂，整个事务处理线被拉长也会导致TPS上不去。
个人理解：
一个事务下的请求多，自然事务的响应时间长，事务的TPS低；但是从请求本身来看，是不受影响的？

八、系统架构

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

附性能瓶颈原因

1、硬件上的性能瓶颈：
一般指的是CPU、内存、磁盘读写等的瓶颈，为服务器硬件瓶颈。
2、应用软件上的性能瓶颈：
一般指的是服务器操作系统瓶颈（参数配置）、数据库瓶颈（参数配置）、web服务器瓶颈（参数配置）、中间件瓶颈（参数配置）等
3、应用程序上的性能瓶颈：
一般指的是开发人员，开发出来的应用程序（如sql语句、数据库设计、业务逻辑、算法等）。
4、操作系统上的性能瓶颈：
一般指的是Windows、linux等操作系统，如出现物理内存不足时，或虚拟内存设置不合理（虚拟内存设置不合理，会导致虚拟内存的交换率大大降低，从而导致行为的响应时间大大增加，可以认为在操作系统上出现了性能瓶颈）。
5、网络设备上的性能瓶颈：
一般指的是防火墙、动态负载均衡器、交换机等设备。

性能瓶颈原因定位十分复杂，需抽丝剥茧逐一排除，以上信息仅供参考。

性能测试常见问题-TPS上不去