深入理解TPS、响应时间、并发量

TPS 和 QPS

TPS：Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标。

具体事务的定义，都是人为的，可以一个接口、多个接口、一个业务流程等等。一个事务是指事务内第一个请求发送到接收到最后一个请求的响应的过程，以此来计算使用的时间和完成的事务个数。

以单接口定义为事务为例，每个事务包括了如下3个过程：

　　a.向服务器发请求

　　b.服务器自己的内部处理（包含应用服务器、数据库服务器等）

　　c.服务器返回结果给客户端

　　如果每秒能够完成N次这三个过程，tps就是N；

如果多个接口定义为一个事务，那么，会重复执行abc，完成一次这几个请求，算做一个tps。

简单例子：在术语中解释了TPS是每秒事务数，但是事务时要靠虚拟用户做出来的，假如1个虚拟用户在1秒 内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务 响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生 1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。

QPS：Queries Per Second，意思是每秒查询率，是一台服务器每秒能够响应的查询次数（数据库中的每秒执行查询sql的次数），显然，这个不够全面，不能描述增删改，所以，不建议用qps来作为系统性能指标。

TPS（Transaction per Second）作用：

反映了系统在同一时间内处理业务的最大能力，这个数据越高，说明处理能力越强，描述（看到系统的TPS随着时间的变化逐渐变大，而在不到多少分钟的时候系统
　　每秒可以处理多少个事物。这里的最高值并不一定代表系统的最大处理能力，TPS会受到负载的影响，也会随着负载增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。）
　　而在几分钟以后开始出现少量的失败事物）。

TPS是从客户端角度审视服务器处理能力，不能证明TPS可以达到什么程度就能支持多少并发，两者没有必然联系。
TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。

QPS（TPS），并发数、响应时间它们三者之间的关系是：

QPS（TPS）= 并发数/平均响应时间。

 如何获取Vu和TPS

并发用户数(Vu)获取

新系统：没有历史数据作参考，只能通过业务部门进行评估。

旧系统：对于已经上线的系统，可以选取高峰时刻，在一定时间内使用系统的人数，这些人数认为属于在线用户数，并发用户数取10%就可以了，例如在半个小时内，使用系统的用户数为10000，那么取10%作为并发用户数基本就够了。

TPS获取

新系统：没有历史数据作参考，只能通过业务部门进行评估。

旧系统：对于已经上线的系统，可以选取高峰时刻，在5分钟或10分钟内，获取系统每笔交易的业务量和总业务量，按照单位时间内完成的笔数计算出TPS，即业务笔数/单位时间（5*60或10*60）

如何评价系统的性能

针对服务器端的性能，以TPS为主，并发用户数为辅来衡量系统的性能。

如果必须要用并发用户数来衡量的话，需要一个前提，那就是事务在多长时间内完成。

因为在系统负载不高的情况下，并发用户数可以一直增加，响应时间不变，负载过大时，并发用户数增加，响应时间增大。

因此用并发用户 数来衡量系统的性能没太大的意义。

 并发数、QPS、平均响应时间三者之间关系图。