性能常识 性能测试常用概念
一、在线用户数
在线用户数指的是登录系统的用户，也就是系统的在线数量，包括正在系统上处理业务的用户和挂机的用户
二、并发用户数
在很多人的理解中，认为并发用户数为压力机发起的线程数，然而并不是这样，当压力机同时发起 20 个线程，那实际到达服务端的并不是 20 个线程，因为从压力机到服务端这中间存在网络传输，硬件资源配置等情况导致将少于 20 个线程，在性能测试中，并发往往用 TPS 来描述，如：并发数为 20TPS，就是 1S 内系统处理了 20 个事务，是服务端实际处理的事务数量
三、在线用户数和并发用户数的计算
对于一个系统来说，在线用户数是可以统计出来的，对于同一段时间内系统处理业务的数量也是可以统计出来的，进而可以算出某个时间段内的系统的 TPS,假如系统的 TPS 是 100，在线用户数是 1000，可以理解为现在我们系统有 1000 个用户在线，但是系统正在处理的事务只有 100 个，那么可以计算出系统的并发度：100/1000=10%，那么在测试性能的时候，如何确定需要多少个线程呢，首先假设每个线程产生的 TPS 是 20 个，由于并发是 100，所以线程只需要 5 个就够了
四、TPS 的计算
假设：一个用户操作一个流程花费 200s，总共涉及到了 100 个请求,分为 7 个操作，那 TPS 该如何计算
- 如果设置每个请求为一个事务，则 TPS:
1x100/200=0.5，其中 1 表示一个用户，100 表示 100 个请求，200 表示整个流程花费的时间，结果 0.5 表示的就是该事务的 TPS
- 如果设置每个业务操作为一个事务，则 TPS:
1x7/200=0.035,其中 1 表示一个用户，7 表示 7 个业务操作，但是每个业务操作的请求数并不一致，200 表示操作 7 个业务花费的时间，结果 0.035 表示该事务的 TPS
- 如果设置每个用户操作为一个事务，则 TPS:
1x1/200=0.005,其中第一个 1 表示的是一个用户，第二个 1 表示的是用户级别的事务，200 表示操作整个用户级事务花费的时间，结果 0.005 表示该事务的 TPS
由此可见：当设置事务为不同级别的时候，所计算出来的 TPS 也是不同的
五、如何确定压力机需要多少线程
压力机的线程和 TPS 以及在线用户数是有关系的，当在线用户数和 TPS 确定后，就可以确定需要多少个线程了，假如要模拟 10 万用户在线，而一个压力线下的 TPS 是 200，则压机机线程=10 万/200=500 个。
想交流下，在线用户数这个数据，以及由此衍生出的并发度概念，在实际性能测试里面，会怎么使用？
个人理解，在线用户数增加，实际增加的只是内存或者用户信息存储中间件（如 redis）的消耗。只要大致了解每个用户消耗的资源情况，以及系统配置的总资源大小，基本就可以倒推出最大可以支持的在线用户数了。至于并发度，个人觉得这个数据很难做到准确（不同时段、不同场景、甚至不同用户，并发度都会有很大差异），所以好像没什么适合使用的地方？
另外，里面提到的 每个业务操作为一个事务、每个用户操作为一个事务 ，感觉这个 TPS 在实际操作中并不好计算，而且也和开发日常接触运维监控数据里的 TPS/QPS 差异比较大。个人实际项目里用的 TPS 概念，一般直接用压测工具计算的 TPS ，即此接口在此次压测下，每秒完成处理的请求数。
最后，每个线程产生的 TPS 是 20 个、一个压力线程下的 TPS 是 200 ，这里每个线程产生的 TPS 是怎么计算的？平时很少接触到每个线程产生多少 TPS 这样的概念，个人实际应用，根据接口本身逻辑的复杂度，同样一个线程，在简单接口达到过千 TPS，在复杂接口降到只有几十 TPS，都会存在，没有相对固定的值。而且随着压测线程数增加，如果已经达到系统性能瓶颈，那系统总 TPS 会保持稳定，进而平均到每个压测线程的 TPS 也在减少，所以比较好奇这个值要怎么算？
并发度其实是计算出来的，意思就是并发数占在线用户数的比例是多少，比如一个系统的在线用户数是 100，但是这 100 个在线用户数有的可能是在系统上挂着的，没有对系统产生压力，对系统产生压力的只有 20 个，这 20 个就是并发数，并发度就是 20%