TPS，执行一次事务(包括请求，请求服务器，等地服务器返回等等，比如一个TPS事务，可能触发3个QPS请求)
一秒钟处理的事务数，TPS值越大，一秒钟处理的事务数量就越多，说明处理速度越快，软件的效率就越好
TPS：Transactions Per second(每秒传输的事务处理个数)，即服务器每秒处理的事务数，TPS至少包括一条消息入和一条消息出，加上一次数据的访问
TPS是软件测试结果的测量单位，一个事务是指一个客户机想服务器发送请求然后服务器做出响应的过程。客户机在发送请求时开始计时，收到服务器响应后结束时，以此来计算使用的时间和完成事务的个数
一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量，系统整体处理能力取决于处理能力最低模块的TPS值：如1秒50并发，持续60s，发现实际接口请求书1461个，时间60s，TPS比较稳定，TPS大概在23左右，所以当前这个接口，系统能处理的事务在24左右，TPS=请求数/时间
TPS实例解释：TPS是每秒事务数，但是事务是要靠虚拟用户做出来的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1，如果某笔业务响应时间是1ms，那么1个用户在1s内能完成1000笔事务，TPS就是1000了，如果某笔业务响应时间是1s，那么1个用户1秒内完成1笔事务，如果想要打到1000TPS，至少需要1000个用户，因此可以说1个用户可以产生1000TPS，1000个用户也可以产生1000tps，无非就是看响应时间的快慢。得出结论：衡量系统的性能不能用并发用户数
并发用户数（Vu）获取：
新系统：没有历史数据作为参考，只能通过业务部门进行评估(参考同类的产品数据)
旧系统:对于已经上线的系统，可以选取高峰时刻，在一定时间内使用系统的人数，这些人数认为属于在线用户数，并发用户数取10%就可以了，列如半小时内，使用系统的用户数为1万，那么取10%作为并发用户数基本就够了(基准测试)
TPS获取：
新系统：没有历史数据作为参考，只能通过业务部门进行评估
旧系统：对于已经上线的系统，可以选取高峰时刻，在5分钟或者10分钟内或者半小时内(连续采集一周，或者一个月时间的数据)，获取系统每笔交易的业务量和总业务量，按照单位时间内完成的笔数计算出TPS，即业务笔数/单位时间
如：连续采样一周，预估半小时内业务笔数是3万，预估TPS是3万/3600s
总结：系统的性能由TPS决定，跟并发用户数没有太多的关系，在同的TPS下，可以由不同的用户数去压(通过加思考时间设置)
系统的最大TPS是一定的（在一个范围内），但是并发用户不一定，可以调整
建议性你那个测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压，一般情况下，大型系统(业务量，机器多)做压力测试，5000个用户并发就够了，中小型系统做压力测试，1000个用户并发就足够了