先说理解：
- 系统的性能由TPS决定，跟并发用户数没有多大关系。在同样的TPS下，可以由不同的用户数去压（通过加思考时间设置）。
- 系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。
- 建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。
- 一般情况下，大型系统（业务量大、机器多）做压力测试，5000个用户并发就够了，中小型系统做压力测试，1000个用户并发就足够了。
1.策略
做性能测试需要一套标准化流程及测试策略，并发用户数只是指标考虑的一个，在做负载测试的时候，一般都是按照梯度施压的方式去加用户数，而不是在没 有预估的情况下，一次加几万个用户，，交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内，这样做没有多大的意义，这就好比“有多少钱可以干多少事”一样，需要选择相关的策略。
性能测试中TPS上不去的几种原因浅析
昨晚在某个测试群看到有人问了一个问题：压力测试中TPS一直上不去，是什么原因？稍微整理了下思路，列举性的简略回答了他的问题。
这篇博客，就具体说说在实际压力测试中，为什么有时候TPS上不去的原因。如有遗漏或不对的，请评论区指出，不胜感激。。。
先来解释下什么叫TPS：
TPS（Transaction Per Second）：每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量，一般以request/second为单位。
关于性能测试的其他一些常见术语，可参考之前的博客：性能测试：常见术语浅析
下面就说说压测中为什么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、系统架构
比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。
转https://www.cnblogs.com/imyalost/p/8309468.html
标签：缓存,性能,并发,TPS,测试,连接池 From： https://www.cnblogs.com/testcodell/p/16975932.html