并发数是15TPS，就是1秒内整个系统处理了15个事务。
2 在线用户数、并发用户数怎么计算总共有30个用户，有10个用户数没有任何动作，有20个就是并发用户数，这时的并发度就是2/3*100%.
为了能hold住更多的用户，还会把一些数据放到redis这样的缓存服务器中。所以在线用户数就可以看缓存内存
1）如果有10000个在线用户数，并发度1%，那么显然并发用户数就是100.
2）如果每个线程的20TPS，显然只要5个线程（压力机的5个线程）
3）对于Server，它是处理就是100TPS，平均响应时间是50ms。50ms就是根据1000ms/20TPS算的（注意：平均响应时间会在一个区间内浮动，但只要TPS不变，这个平均响应时间就不会变）
4）如果有两个Server线程处理，一个线程就是50TPS
并发依赖TPS来承载的时候，指的是Server端的处理能力，并不是压力工具上的并发线程数。并发是指服务器上100TPS的处理能力，不是指5个压力机的并发线程数
3.1 示例1：JMeter（1 个线程） - Nginx - Tomcat - MySQL
summary + 5922 in 00:00:30 = 197.4/s Avg: 4 Min: 0 Max: 26 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0 summary = 35463 in 00:03:05 = 192.0/s Avg: 5 Min: 0 Max: 147 Err: 0 (0.00%) summary + 5922 in 00:00:30 = 197.5/s Avg: 4 Min: 0 Max: 24 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0 summary = 41385 in 00:03:35 = 192.8/s Avg: 5 Min: 0 Max: 147 Err: 0 (0.00%) summary + 5808 in 00:00:30 = 193.6/s Avg: 5 Min: 0 Max: 25 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0 summary = 47193 in 00:04:05 = 192.9/s Avg: 5 Min: 0 Max: 147 Err:
平均响应时间都是在5ms左右，只有1个压力机，这个TPS接近1000ms/5ms=200TPS。这个数据是30s刷新一次，用30秒的时间内完成的事务数除以30秒得到的，如果事务数还没有完成，就不会计算在内了，如果这段时间内有一两个时间长的食物，也会拉低TPS。
服务端线程工作情况
服务端开了5个线程，大那是服务端只有一个干货，这是一种合理状态，但是不一定是对的性能状态。
3.2 示例2：下面换个一个场景，压力机启动10个
summary + 11742 in 00:00:30 = 391.3/s Avg: 25 Min: 0 Max: 335 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0 summary = 55761 in 00:02:24 = 386.6/s Avg: 25 Min: 0 Max: 346 Err: 0 (0.00%) summary + 11924 in 00:00:30 = 397.5/s Avg: 25 Min: 0 Max: 80 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0 summary = 67685 in 00:02:54 = 388.5/s Avg: 25 Min: 0 Max: 346 Err: 0 (0.00%) summary + 11884 in 00:00:30 = 396.2/s Avg: 25 Min: 0 Max: 240 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0 summary = 79569 in 00:03:24 = 389.6/s Avg: 25 Min: 0 Max: 346 Err:
平均响应时间是在25ms，TPS为（1000ms/25ms）*10=400TPS
服务端的线程
这里的5个线程就是忙了许多
1）并发用户数是396.2TPS。如果并发度为5%，在线用户数就是396.2/5%=7924
2）响应时间是25ms。
3）压力机并发线程数是10.
TPS反应的是和服务器对应的处理能力，一般我们关心的就是TPS和响应时间。
3.3 微服务中
每个服务都只需要做1个事情，拆分的很细，注意整个系统的容量水位，不是看某一个服务的能力，这个就是拉平整个系统的容量。
