问者：每秒处理的事物数和事物的平均响应时间 怎么个关系，有关系吗
kaku21：举个例子：一个高速路 有10个入口，每个入口每秒钟只能进1辆车，请问1秒钟最多能进几辆车？？
问者：10
kaku21：每辆车需要多长时间响应？？
问者：针对这个问题的话 那tps就是10 ，事物的响应时间是1
kaku21:好，那现在我有20辆车，那每秒能进几辆？？每辆响应时间是多少？？
问者：。。。思考中
kaku21:每秒还是进10辆车呗，每辆车还是1秒响应啊
问者：对呀
kaku21:继续，现在我把入口扩展到20个，那我问你，每秒最多进多少辆车？？每辆车响应多长时间？？
问者：20 1
kaku21:好，现在tps变了，响应时间没变，那我问你 tps跟响应时间有啥关系？？
问者：没关系
kaku21: tps和响应时间在理想状态下都是额定值，你把入口看做线程池。如果20个入口，并发数只有10的时候，tps就是10，而响应时间始终都是1，说明并发不够，需要增加并发数达到tps的峰值。
问者：同样是20个入口，并发数是100的话，tps是20，响应时间还是1？
什么情况下响应时间会大于1秒
kaku21:我问你，当并发数量是100的时候，会出现什么情况？？
问者：堵车啦。。。哦，堵车了 平均每个车过去的时间就长了？
kaku21:堵车说白了就是有车在等待，现在把100按20分成5份，第5份等待的时间是最长的，从等待开始到这个车进去，实际花费了多长时间？？
问者：5秒吧
kaku21:那么100两车的平均响应时间是多少？？
问者：5除以100？0.05？
kaku21:错，用简单的数学逻辑算 (5+4+3+2+1)/5=3 这就是平均响应时间
明白没？？接着问你，100两车的平均tps是多少？？
问者：20？
kaku21:错(20/1+20/2+20/3+20/4+20/5)/5 约等于 8.8999
问者：前面tps还是20呢 ，并发大了 怎么tps小了.20是tps的峰值？
kaku21:响应时间和TPS在宏观上是反比的关系，但是两者之间没有直接关系
kaku21:20是一次并发的数量，100的并发则造成了线程的等待，引起平均响应时间从1秒变成3秒，当然TPS也从20下降到9;TPS和响应时间都是单独计算出来的，两者不是互相计算出来的。
. 背景
在做性能测试的时候，很多人都用并发用户数来衡量系统的性能，觉得系统能支撑的并发用户数越多，系统的性能就越好；对TPS不是非常理解，也根本不知道它们之间的关系，因此非常有必要进行解释。
2. 术语定义
- 并发用户数： 指的是现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)，注意并发用户数跟注册用户数、在线用户数有很大差别的，并发用户数一定会对服务器产生压力的，而在线用户数只是 “挂”在系统上，对服务器不产生压力，注册用户数一般指的是数据库中存在的用户数。
- TPS ： Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标，
3. Vu和TPS换算
TPS是每秒事务数，但是事务是要靠虚拟用户做出来的，假如1个虚拟用户在1秒 内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务 响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生 1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。
4. 如何获取Vu和TPS
- 并发用户数(Vu)获取
新系统：没有历史数据作参考，只能通过业务部门进行评估。
旧系统：对于已经上线的系统，可以选取高峰时刻，在一定时间内使用系统的人数，这些人数认为属于在线用户数，并发用户数取10%就可以了，例如在半个小时内，使用系统的用户数为10000，那么取10%作为并发用户数基本就够了。
- TPS获取
新系统：没有历史数据作参考，只能通过业务部门进行评估。
旧系统：对于已经上线的系统，可以选取高峰时刻，在5分钟或10分钟内，获取系统每笔交易的业务量和总业务量，按照单位时间内完成的笔数计算出TPS，即业务笔数/单位时间（5*60或10*60）
5. 如何评价系统的性能
针对服务器端的性能，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能，如果必须要用并发用户数来衡量的话，需要一个前提，那就是交 易在多长时间内完成（系统响应时间），因为在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到脚本中，并发用户数基本可以增加一倍，因此用并发用户 数来衡量系统的性能没太大的意义。
- 系统响应时间：
系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径就是系统响应时间，关键路径是由CPU运算、IO、外部系统响应等组成。
响应时间= 网络传输时间 + 应用服务器处理时间 + 数据库服务器处理时间
6. 相关案例
通过大量性能测试我们发现不需要用上万的用户并发去进行测试，只要系统处理业务时间足够快，几百个用户甚至几十个用户就可以达到目的。另外咨询很多专家做过的性能测试项目，基本都没有超过5000用户并发。
因此对于大型系统、业务量非常高、硬件配置足够多的情况下，5000用户并发就足够了；对于中小型系统，1000用户并发就足够了。
7. 性能测试策略
做性能测试需要一套标准化流程及测试策略，并发用户数只是指标考虑的一个，在做负载测试的时候，一般都是按照梯度施压的方式去加用户数，而不是在没 有预估的情况下，一次加几万个用户，，交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内，这样做没有多大的意义，这就好比“有多少钱可以干多少事”一样，需要选择相关的策略。
8. 总结
- 系统的性能由TPS决定，跟并发用户数没有多大关系。在同样的TPS下，可以由不同的用户数去压（通过加思考时间设置）。
- 系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。
- 建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。
- 一般情况下，大型系统（业务量大、机器多）做压力测试，5000个用户并发就够了，中小型系统做压力测试，1000个用户并发就足够了。