在我们的这个理发店中，我们事先做了如下的假设：

1. 理发店共有3名理发师；（系统资源、服务器）

2. 每位理发师剪一个发的时间都是1小时；(处理时间)

3. 我们顾客们都是很有时间观念的人而且非常挑剔，他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，我们的顾客会立马生气的走人。（用户可以容忍的系统响应时间为3小时，超过这个时间用户可能会重新请求或者不再请求）

通过上面的假设我们不难想象出下面的场景：

场景一：

            当理发店内只有1位顾客时，只需要有1名理发师为他提供服务，其他两名理发师可能继续等着，也可能会帮忙打打杂。1小时后，这位顾客剪完头发出门走了。那么在这1个小时里，整个理发店只服务了1位顾客，这位顾客花费在这次剪发的时间是1小时；

场景二：

            当理发店内同时有两位顾客时，就会同时有两名理发师在为顾客服务，另外1位发呆或者打杂帮忙。仍然是1小时后，两位顾客剪完头发出门。在这1小时里，理发店服务了两位顾客，这两位顾客花费在剪发的时间均为1小时；

场景三：

            很容易理解，当理发店内同时有三位顾客时，理发店可以在1小时内同时服务三位顾客，每位顾客花费在这次剪发的时间仍然是均为1小时；

从上面几个场景中我们可以发现，在理发店同时服务的顾客数量从1位增加到3位的过程中，随着顾客数量的增多，理发店的整体工作效率在提高，但是每位顾客在理发店内所呆的时间并未延长。（当并发用户数小于最佳并发用户数时，随着用户的增加，响应时间并不会增加，只是系统资源利用率增加了）

当然，我们可以假设当只有1位顾客和2位顾客时，空闲的理发师可以帮忙打杂，使得其他理发师的工作效率提高，并使每位顾客的剪发时间小于1小时。不过即使根据这个假设，虽然随着顾客数量的增多，每位顾客的服务时间有所延长，但是这个时间始终还被控制在顾客可接受的范围之内，并且顾客是不需要等待的。

 场景四：

            不过随着理发店的生意越来越好，顾客也越来越多，新的场景出现了。假设有一次顾客A、B、C刚进理发店准备剪发，外面一推门又进来了顾客D、E、F。因为A、B、C三位顾客先到，所以D、E、F三位只好坐在长板凳上等着。1小时后，A、B、C三位剪完头发走了，他们每个人这次剪发所花费的时间均为1小时。可是D、E、F三位就没有这么好运，因为他们要先等A、B、C三位剪完才能剪，所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时和剪发1小时。

通过上面这个场景我们可以发现，对于理发店来说，都是每小时服务三位顾客——第1个小时是A、B、C，第二个小时是D、E、F；但是对于顾客D、E、F来说，“响应时间”延长了。（当并发用户超过最佳并发用户数，随着用户的增加，响应时间会变长）。

 场景五：

            在新的场景中，我们假设这次理发店里一次来了9位顾客，根据我们上面的场景，相信你不难推断，这9位顾客中有3位的“响应时间”为1小时，有3位的“响应时间”为2小时（等待1小时+剪发1小时），还有3位的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了。

场景六：

            假设这次理发店里一次来了10位顾客，根据上面的推算，必然存在一位顾客的“响应时间”为4个小时，而之前我们又做过假设3小时已经是顾客忍耐的极限了，所以这个顾客会因为无法忍受等待时间而离开理发店。

通过以上6个场景我们可以得出以下结论：

    1. 理发店每小时最多对3位顾客进行理发（最佳状态）

    2. 顾客最多等待3小时，如超过，将离开理发店（最大忍耐限度，响应时间最低要求）

    3. 进来的顾客最多为9为，不会出现顾客离开（最大边界值）

    4. 进来顾客超过3位时，每个顾客在理发店的时间是不太一样的（排队有先后的，这表明没有绝对的并发）

性能模型图

在这张图中我们可以看到:

1、最开始，随着并发用户数的增长，资源占用率和吞吐量会相应的增长，但是响应时间的变化不大；

2、不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓甚至停止增长，而响应时间却进一步延长。

3、如果并发用户数继续增长，你会发现软硬件资源占用继续维持在饱和状态，但是吞吐量开始下降，响应时间明显的超出了用户可接受的范围，并且最终导致用户放弃了这次请求甚至离开。

根据这种性能表现，图中划分了三个区域，分别是Light Load（较轻的压力）、Heavy Load（较重的压力）和Buckle Zone（用户无法忍受并放弃请求）。在Light Load和Heavy Load 两个区域交界处的并发用户数，我们称为“最佳并发用户数（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone两个区域交界处的并发用户数则称为“最大并发用户数（The Maximum Number of Concurrent Users）”。

当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；

当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。

对应到我们上面理发店的例子，每小时3个顾客就是这个理发店的最佳并发用户数，而每小时9个顾客则是它的最大并发用户数。

当每小时都有3个顾客到来时，理发店的整体工作效率最高；而当每小时都有9个顾客到来时，前几个小时来的顾客还可以忍受，但是随着等待的顾客人数越来越多，等待时间越来越长，最终还是会有顾客无法忍受而离开。同时，随着理发店里顾客人数的增多和理发师工作时间的延长，理发师会逐渐产生疲劳，还要多花一些时间来清理环境和维持秩序，这些因素将最终导致理发师的工作效率随着顾客人数的增多和工作的延长而逐渐的下降，到最后可能要1.5小时甚至2个小时才能剪完1个发了。

当然，如果一开始就有10个顾客到来，则注定有1位顾客剪不到头发了。

进一步理解“最佳并发用户数”和“最大并发用户数

 对于一个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发用户数”和“最大并发用户数”都是客观存在。以“最佳并发用户数”为例，假如一个系统的最佳并发用户数是50，那么一旦并发量超过这个值，系统的吞吐量和响应时间必然会 “此消彼长”；如果系统负载长期大于这个数，必然会导致用户的满意度降低并最终达到一种无法忍受的地步。

所以我们应该保证最佳并发用户数要大于系统的平均负载。

 要补充的一点是，当我们需要对一个系统长时间施加压力——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么。（每过一个小时来3个理发的，3个理发师会不停的剪发，而用户不需要等待。理发师处于这种状态很长时间后当然会崩溃）

 而对于最大并发用户数的识别，需要考虑和鉴别一下以下两种情况：

1.当系统的负载达到最大并发用户数后，响应时间超过了用户可以忍受的最大限度——这个限度应该来源于性能需求，例如：在某个级别的负载下，系统的响应时间应该小于5秒。这里容易疏忽的一点是，不要把顾客因为无法忍受而离开时店内的顾客数量作为理发店的“最大并发用户数”，因为这位顾客是在3小时前到达的，也就是说3小时前理发店内的顾客数量才是我们要找的“最大并发用户数”。而且，这位顾客的离开只是一个开始，可能有会更多的顾客随后也因为无法忍受超长的等待时间而离开；

2.在响应时间还没有到达用户可忍受的最大限度前，有可能已经出现了用户请求的失败。以理发店模型为例，如果理发店只能容纳6位顾客，那么当7位顾客同时来到理发店时，虽然我们可以知道所有顾客都能在可容忍的时间内剪完头发，但是因为理发店容量有限，最终只好有一位顾客打道回府，改天再来。

对于一个系统来说，我们应该确保系统的最大并发用户数要大于系统需要承受的峰值负载。

理发店模型的进一步扩展（解决方法）

扩展场景1：

        有些顾客已经是理发店的老顾客，他们和理发师已经非常熟悉，理发师可以不用花费太多时间沟通就知道这位顾客的想法。并且理发师对这位顾客的脑袋的形状也很熟悉，所以可以更快的完成一次理发的工作。（类似于相同的账号登陆，如果一直使用一个账号发送请求和参数化不同的用户请求响应时间是不一样的）

 扩展场景2：

        理发店并不是只有剪发一种业务，还提供了烫发染发之类的业务，那么当顾客提出新的要求时，理发师服务一位顾客的时间可能会超过标准的1小时。而且这时如果要计算每位顾客的等待时间就变得复杂了很多，有些顾客的排队时间会比原来预计的延长，并最终导致他们因为无法忍受而离开。（不同用户发送不同的请求，有的只是登陆，有的登陆后进行其他操作）

扩展场景3：

        随着烫发和染发业务的增加，理发师们决定分工，两位专门剪发，一位专门负责烫发和染发。（分配不同的服务器，不同的服务器提供不同的功能）

 扩展场景4：

        理发店的生意越来越好，理发师的数量和理发店的门面已经无法满足顾客的要求，于是理发店的老板决定在旁边再开一家店，并招聘一些工作能力更强的理发师。（增加处理能力更强的服务器）

扩展场景5：

        理发店的生意变得极为火爆了，两家店都无法满足顾客数量增长的需求，并且有些顾客开始反映到理发店的路途太远，到了以后又因为烫发和染发的人太多而等太久。可是理发店的老板也明白烫发和染发的收入要远远高于剪发阿，于是他脑筋一转，决定继续改变策略，在附近的几个大型小区租用小的铺面开设分店，专职剪发业务；再在市区的繁华路段开设旗舰店，专门为烫发、染发的顾客，以及VIP顾客服务。并增设电话，当顾客想要剪发时，可以拨打这个电话，并由服务人员根据顾客的居住地点，将其指引到距离最近的一家分店去。（预约）

借鉴：

        借助这个模型，理解了响应时间、吞吐量、资源占用率、最佳并发用户、最大并发用户。在这个模型中，需要理发的人员（即客户）向理发店（服务器）提出理发的请求，理发师的剪发时间为1小时，即服务器的处理时间，用户的响应时间为进入理发店的门到理发完毕的时间（等待时间+处理时间）。理发店共有3个理发师（系统资源）。

        当3个用户并发请求理发时，此时系统资源占用达到饱和，此时资源利用率也是最高的，因为所有的理发时都在忙，没有闲着的。此时的理发人数即最佳并发用户数。

        如果再有理发请求，客户需要等待，无法及时响应。当同时到达理发店的人员（并发用户）多于3个，比如9个时，有3个用户响应时间为2小时（1小时等待+1小时理发），还有3个用户响应时间为3小时。即当超过最佳并发用户时，随着用户的增加，系统响应时间变长。

       当超过9个用户，同时有10个用户到达理发店理发时，因为第7 8 9用户理完发时，第10个用户已经等待了3个小时，超过的他的极限，所以用户离开了。选择改天再来，或者不来了。即在实际中，用户请求页面，如果页面响应很慢，超过了10s 20s或者更长，用户等待烦了，会选择重新请求或者不再请求。9个用户的时候即为最大并发数，因为超过9个时，就会有超过一个的用户得不到响应。

补充解决方法：

1. 增加理发师（增加资源、服务器）

2. 理发师技能提高，如何能缩短理发师时间

3. 预约理发（提升性能，增加用户体验）

4. 增开分店（增加分店）

5. 上班时间

6. 理发店里，为顾客理发有高峰期，不在高峰期时，可以留一两个理发师打理，这样节约成本，知道某个时间端是有峰值的，那么在这段时间多派几个理发师来，进行工作（和性能一样都有一个高峰期，没有高峰期将服务器结点摘出去，高峰期来临时，再将结点加进去，起到一个分流的作用）

实际中为缓解并发的性能，会采用验证码、注册码等，例如：去一家购物网站抢购商品，在购物之前，可以做一个调查什么的

性能测试不能狭隘到只是后端性能测试

     对于真正完整的性能测试，后端的性能测试只是他的一小部分，对于前端的，对于性能测试站在用户角度体验做的一些展现或是策略，产品设计上的优化都属于性能测试的范围。

软件性能的基本概念

从三个不同层面来对性能进行阐述：

1、从用户角度，软件性能就是软件对用户操作的响应时间

2、从管理员角度，软件性能表现在系统的响应时间，不单关注用户体验之外，还关心和系统状态相关的信息

3、从开发员角度，软件性能表现在如何调整设计和代码的实现，通过调整系统的设置等提高性能

这如同理发店模型中的顾客、老板和理发师 

1、顾客关心的是理发需要的时间（用户）

2、老板关注的是如何提高顾客数量（管理员）

3、理发师所考虑最多的是提高自己的理发技艺，如何能缩短理发的时间等（开发员）

故考虑性能测试，必须从不同角度去思考问题，从用户角度和从应用系统角度来看性能测试，理解上会有些差异。

做性能测试还是理解性能测试一定要互换角度的思维，在不同角度上去看系统的性能

    测试、开发、运维、领导等角度上，包括以后写报告针对于不同对象，写的报告侧重点不同，可以写一份基本的测试报告，针对于角色不同，在基本的测试报告填写东西，给不同的角色去看。