所谓的性能，是负载、吞吐量、可接受的响应时间和资源利用率之间的一种平衡。
通过一个理发店的例子，然后引出最佳并发用户数和最大并发用户数的概念
背景：理发店共有3名理发师，每名理发师完成一次理发都耗时1小时，店里有还有一些位子供客人等位，每个客人在理发店呆的时间超过3小时就会无法忍受离开。
3名理发师，好比应用同时能处理几个事务
理发耗时1小时，好比完成一次事务需要的时间
（等待位子，加上能剪发的位子，好比最大请求队列数）
3小时，好比响应时间，超过3小时，则放弃这个请求
结合场景，从上图可以看出，随着理发店客人的数量增加时，响应时间一开始并没有明显变化，因为有3个理发师，足矣消化掉3个客人，当超过3个客人时，势必有客人是需要等待的。
在客人数量正好为3人时，理发师的工作效率最高，客人也不需要等待，这个数我就理解为 最佳并发用户数
而当客人数为9人时，在这个场景中，势必有客人完成理发的时间要达到2-3小时了（来的时候，其他客人已经剪到一半了，需要等正在剪的客人0-1小时，前面排在前面的人理发1小时，自己理发1小时），而再来客人的话，必定完成理发的时间超过3小时，也就是所谓的超时放弃走人了。
这个9，我就理解为 最大并发用户数。
==================================================
对于一个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发用户数”和“最大并发用户数”都是客观存在。以“最佳并发用户数”为例，假如一个系统的最佳并发用户数是50，那么一旦并发量超过这个值，系统的吞吐量和响应时间必然会 “此消彼长”；如果系统负载长期大于这个数，必然会导致用户的满意度降低并最终达到一种无法忍受的地步。所以我们应该 保证最佳并发用户数要大于系统的平均负载。
要补充的一点是，当我们需要对一个系统长时间施加压力——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么 ^_^
而对于最大并发用户数的识别，需要考虑和鉴别一下以下两种情况：
1.当系统的负载达到最大并发用户数后，响应时间超过了用户可以忍受的最大限度——这个限度应该来源于性能需求，例如：在某个级别的负载下，系统的响应时间应该小于5秒。这里容易疏忽的一点是，不要把顾客因为无法忍受而离开时店内的顾客数量作为理发店的“最大并发用户数”，因为这位顾客是在3小时前到达的，也就是说3小时前理发店内的顾客数量才是我们要找的“最大并发用户数”。而且，这位顾客的离开只是一个开始，可能有会更多的顾客随后也因为无法忍受超长的等待时间而离开；
2.在响应时间还没有到达用户可忍受的最大限度前，有可能已经出现了用户请求的失败。以理发店模型为例，如果理发店只能容纳6位顾客，那么当7位顾客同时来到理发店时，虽然我们可以知道所有顾客都能在可容忍的时间内剪完头发，但是因为理发店容量有限，最终只好有一位顾客打道回府，改天再来。
对于一个系统来说，我们应该确保系统的最大并发用户数要大于系统需要承受的峰值负载。
==================================================
系统吞度量要素：
一个系统的吞度量反映的是服务器承受的压力。承压能力与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间
QPS（TPS）：每秒钟request/事务 数量
并发数： 系统同时处理的request/事务数
响应时间： 一般取平均响应时间
理解了上面三个要素的意义之后，就能推算出它们之间的关系：
QPS（TPS）= 并发数 / 平均响应时间
一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。
参考