以下是我自己录制的关于这篇文章的一小段视频，有兴趣的可以下载看看
https://yunpan.cn/cPQc4mm2DjbMu 访问密码 a76f
//此篇摘抄于虫师博客，个人觉得通俗易懂
关于理解性能，记得我那时是看了“《LoadRunner没有告诉你的》之三---理发店模式”不管你有没有看过，我这重提一下理发店模式。
前提：
1. 一个理发店有三位理发师傅
2. 每位理发师傅理一个发需要一小时
3. 顾客都很忙，从进理发店起最多只等三小时（等待时间+理发时间），如果三小时后还没轮到自己理发，立马走人。
思考：
这里我们来理解“最佳用户数”和“最大用户数”。
最佳用户数：
理发店的最佳状态，理发店收入最多（理发师傅没有休息时间，一直在理发），顾客满意度最高（顾客随时到随时理，无需要等待）。在一个时间点来说，三个理发师傅服务于三位顾客，那么这个最佳用户数是三。
最大用户数：
理发店的最大承受状态，理发店收入最多（理发师傅没有休息时间，一直在理发），顾客的最大忍耐度（来的顾客等待+理发需要等上三个小时）。
假如理发店生意非常好，早上一开门一下子来了一群顾客（很多），A、B、C三位顾客先理，D、E、F顾客需要等待一小时才能得到理发师傅的服务，G、H、I三位顾客等待了两小时才得到服务，后面排队的J、K、L.....等顾客，已经等了三小时还没得到服务，因为这已经得达到了他们等待的极限，所以后他们气愤和无奈离开。
当然，理发店还会不断的来新的顾客，不断有等了三小时而没有得到服务的顾客离开，但对于理发店而言，他们在一个时间点上，能服务的最大用户数是九（三位正在接受服务、三位已经等待一小时，三们已经等待两小时）。
对于最大用户数，需要注意的两点：
1. 在理发店里很大，可以容纳很多位顾客（大于9），总有一部分在这里等待了三小时而没有得到服务离开，不要把等待了三小而没有得到服务的顾客纳入最大用户数里。
2. 假如理发店很小，最多只能容纳六位顾客，当第七个顾客来时，虽然，我们知道他只需要等待两小时就可得到服务（这个时间是他可以接受的等待时间），但由于理发店容量有量，这第七个顾客只有改天再来了。
关于理发店原理，详细请浏览http://www.cnblogs.com/jackei/archive/2006/11/20/565527.html
不知道通过上面对理发店的分析，你对性能有了一些眉目。假如理发店相当于我们的系统的话，顾客就我们向服务器所发送的请求，最佳用户数和最大用户数是我们衡量一个系统的处理能力的一种方法。
这个是我在给一朋友说浏览器与服务器之间交流时用到的例子，感觉比容易理解，所以拿来分享一下。
假设：
1. A、B、C三个人。
2. C欠A钱（这里不考虑多少）
3. B是专门要账
思考：
浏览器与服务器的信息传递次数：
A对B说，C欠我钱，你帮我去要。B接到指令后就去找C要钱。
B对C说，给我20块钱。
C说，没有。
B对C说，给我10块钱。
C说，没有。
B对C说，给我5块钱。
.........
最后，B回来对A说，哎呀妈呀，C那丫的忒抠门了，一分钱没有。
对于A来讲，只是来说，它只是让B问C要钱，具体的B与C之间交互了几次，A是不知道的，它所知道的就是B返回给它的结果，C一分钱没有。
浏览器与服务器传递数据的大小：
还是上面的过程，A对B说，C欠我钱，你帮我去要。B接到指令后就去找C要钱。
B对C说，给我20万块钱。
C说，没问题，没支票，只有1元硬币。
..........
B终于把钱拿回来给A。A很纳闷，怎么去了那么久，B委屈的说，丫的，C给我整了一堆硬币，太重了，路上走的慢，都快累死我了。
对于A来讲，只是来说，它只是让B问C要钱，谁知道C给的是支票还是硬币。所以，B去要钱消耗的时间就很长。
所以，要想提高浏览器对服务器的访问速度，应该减少数据传递次数与数据传递的大小。
这样就很自然的引出了浏览器的cookie
A在C哪里存了5毛钱。
A对B说，我在C哪里存了5毛钱，你去拿来我看看。B跑去问C要了5毛钱回来给A看。
过了一会，A又对B说，我在C哪里存了5毛钱，你去拿来我看看。B跑去问C要了5毛钱回来给A看。
过了一会，A又对B说，我在C哪里存了5毛钱，你去拿来我看看。这次C烦了，对B说，你把钱放自己口袋里吧，等A要的时候，你来问我5毛的人民币有没有改版，没有改版的话，你就直接把口袋里的5毛钱给A看就行了。
在这里A就相当于我们用户，B相当于浏览器，C是服务器。而cookie就是B的口袋，当然了cookie的用处还很多。比如我们登陆一个系统，提示我们是否保存密码（有的还有期限比如，一个星期或一个月），如果我们保存了，下次再访问登陆时，浏览器就已经帮我们填写好了账户密码或直接帮我们登陆。那这个账户密码就放在我们浏览器的cookie中。
为什么要说上面的例子呢？因为我们大部分的一部分性能测试是基于B/S架构系统的，理解了浏览器与服务器之间的数据传递，有助于我们理解性能测试。
----//在开始性能测试之前，我们需要知道什么?
当客户或老板把你叫来，对你说，去给我们系统做个性能测试，千万别傻傻的说“好！”然后，就走了，我以前这么干过（那时不懂，打肿了脸充胖子），回到座位后，不知从何下手了。
那么，我们需要知道什么呢？
1. 性能测试的目的
首先要知道客户的要求。
我把性能测试按目的分以下几种
1）客户有明确要求
这是一个好的结果，这说明客户对性能测试有一定的了解，知道他们需要的系统要达到一个什么样的标准。如：系统要求同时满足100用户登陆，平均每个用户登陆时间不能超过5秒。这个需求很明确，当然也不排除一些不懂装懂的用户，提一些不现实的要求。
不管怎么说，用户提要求了，这个比较容易，你可以对现系统做一次性能测试，至于，是通过优化系统还是增加硬件设备才能达到要求。就不是我们考虑的问题了。
2）只是想知道目前系统性能（容量测试）
可以把我们的目的就是求得最大用户数和最佳用户数。但是，这仍然是比较含糊的一个需求，我们需要对系统做出分析，找出系统的压力点。
3）找出系统性能瓶颈
这个同样需要分析可能对系统造成瓶颈的逻辑业务，然后才能进行性能测试。
4）了系统在长时间的压力下性能状况（强度测试）
这个一般验证系统的稳定性，因为系统一旦上线，就有可能会长期处在大用户的访问状态，可能以前没发现的一些问题就会暴漏出来。比较典型的就是内存溢出。
2. 性能测试的环境
确定了我们的测试目的，当然需要测试环境。这里的环境，我们需要考虑一下几点
1）硬件环境
我们需要了解被测服务器硬件配置，用于加压客户端的机子配置，CPU 内存 等
2）软件环境
我们需要了解被测系统的架构，前端、中间件、服务器（这里指运行系统软件服务器，如tomcat）、数据库，以及他们的部署位置。
用于加压的客户端采用什么性能测试工具进行加压。
3）网络环境
网络环境很重要。在上面的几个目的中，除了找出系统性能瓶颈可以在广域网进行，因为这个目的可以不用设置太多的虚拟用户，只要找出系统哪个地方影响了整个系统的性能就行。
其他目的的测试都需要在，局域网进行，不然你压力工具所发送的请求都会卡死在网络的传输过程中。
3. 寻找系统的压力点
我们需要对系统的哪个页面或业务进行加压。这个不是自己想出来的，需要与开发人员的沟通。系统的首页？系统的登录？还是系统的交易过程？各个业务的用户比例是多少？
只有获得有效的性能需求，才容易寻找和定位压力点。
获得有效的需求：http://www.cnblogs.com/jackei/archive/2006/12/12/589473.html
----//在开始性能测试之前，我们需要知道的性能测试常见指标
性能测试常见指标
性能测试说白了就是通过工具模拟多个用户对被测系统进行访问。然后查看系统对于多个用户发来请求的处理能力。
左边的两个小人表示两个用户，向右边服务器发送请求，然后得到服务器的响应信息。
首先，我们要保证向服务器发送的请求的正确性，当然用户向服务器发送错误的请求，服务器也会个客户端响应信息，但响应的是报错信息；所以，为了保证测试数据的有效性，我们的要保证发送请求的正确性。
为什么一般的性能测试要在局域进行？
一般我们的性能测试都是在局域网中进行的。为什么一定要在局域网中进行呢？因为局域网中不受网络限制。这个说法不能绝对。但是一般测试工具的用户并发量是不会受到局域网带宽的限制，除非你做的是十万，百万级别的用户并发。相信懂一点网络知识的人都知道，当你上网很慢的时候，比如打开某某网站很慢，你肯定会骂电信的网络不给力，而不会骂这个网站响应速度不给力。因为，请求信息的耗时大部耗在传输过程中。
所以，刚做测试时，我们群里热议论，如果我们每个人都开一个压力工具对百度网站进行加压。百度，服务器会不会挂掉。有测友说这样是不道德人。呵呵！其实，完全不必有这个担心。就一般人家用的带宽，我确保，你向百度服务器发送的请求大部分都死在半路上，就算不死到了百度服务器已经不能叫并发了。何况百度服务器的集群技术以及其他各种分压技术。所以，做性能测试不了解被测系统的架构，以及各种技术的性能。很难做出有效的测试报告。
下面我们看看性能测试的一些技术指标。
Work Load = Virtual Users
工作负荷 = 虚拟用户数
性能测试常见分类
常会别人说到性能测试、负载测试、压力测试、并发测试，很多人都是混合使用，或者一会叫压力测试，一会叫并发测试。这些概念除了非测试人员分不清楚，甚至许多专业测试人员也对这些名词也很模糊。关于这个分类我翻阅了几个本比较好的书籍，他们讲的也比较模糊，没有给出本质上的区别。只是从不同角度和关 注点来解释。好吧我们先来看他们之间比较普遍的解释。
性能测试（狭义）
性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。通俗地说，这种方法就是要在特定的运行条件下验证系统的能力状态。
特点：
1、这种方法的主要目的是验证系统是否有系统宣称具有的能力。
2、这种方法要事先了解被测试系统经典场景，并具有确定的性能目标。
3、这种方法要求在已经确定的环境下运行。
也就是说，这种方法是对系统性能已经有了解的前提，并对需求有明确的目标，并在已经确定的环境下进行的。
负载测试
通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。
特点：
1、这种性能测试方法的主要目的是找到系统处理能力的极限。
2、这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。
3、这种性能测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。
也就是说，这种方法是对一个系统持续不段的加压，看你在什么时候已经超出“我的要求”或系统崩溃。
压力测试（强度测试）
压力测试方法测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误
特点：
1、这种性能测试方法的主要目的是检查系统处于压力性能下时，应用的表现。
2、这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。
3、这种性能测试方法一般用于测试系统的稳定性。
也就是说，这种测试是让系统处在很大强度的压力之下，看系统是否稳定，哪里会出问题。
并发测试
并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。
特点：
1、这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。
2、这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
3、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。
也就是说，这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。
配置测试
配置测试方法通过对被测系统的软硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。
特点：
1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
2、这种性能测试方法一般在对系统性能状况有初步了解后进行。
3、这种性能测试方法一般用于性能调优和规划能力。
也就是说，这种测试关注点是“微调”，通过对软硬件的不段调整，找出这他们的最佳状态，使系统达到一个最强的状态。
可靠性测试
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
特点：
1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。
2、这种性能测试方法需要在压力下持续一段时间的运行。（2~3天）
3、测试过程中需要关注系统的运行状况。
也就是说，这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。
上面的分类绝非全面，还有失效性测试，就是系统局部发生问题时，其它模块是否可以正常的运行。这个在极少数情况下进行，这里就不介绍了。
性能测试分类之我见
上面的类分完了，似乎得到不少专家的认同，并无不妥。但我们在性能测试过程中真的能把它们区别分的很清楚么?你能严格区分出你这次的测试到底并发测试还是压力测试。
笔者第一点不太赞同的是对“性能测试”的定义。笔者认为性能测式测试包含了上面的所有分类。而这种性能测试的定义只是一种狭义上的“性能测试”，属于性能测试的一种。
性能测试是相对功能测试来说的。他们之间最本质的区别就是对系统有处理能力是否够成压力。如果一个用户的一个操作（比如超大数据量的查询）对系统够成了压力，我也可以视其为性能测试。
其实，可以这样来划分性能测试
上面定交了那么多分类，是不是有点晕了。其实，以笔者认为我们进行性能测试时关注的就两点。耐力和爆发力。
初高中时练过几年体育，最好时代表学校参加县体育比赛，不过是去垫底的。哈哈！哈一个体育运动员来说，那么多的体育项目，其实，考核他的就两方面。一是爆发力。二是耐力。
爆发力：拿一个举重选手来说，他的重点在重量上，因为你只要能举起三秒就算你成功了。关键是看你能举起一个什么样的重量。
耐力：拿一个马拉松运动员来说，你百米速度跑得再快没用。关键是这40公里路程中，最先跑到终点的人才是赢家。
整体协调性：当然，身为一个教练员，我在选拔选手的时候，除了看这个运动员的耐力和爆发力，身体的整体协调性也是我考核的一个很重要的指标。比如一个运行员身体各位部位练得非常强壮，但右臂先天性萎缩。他的跑步成绩虽然不错。但他在跑的过程中，身体有各个部分都在分担右臂的不足。右臂影响了整个体能的发挥。
再到系统的性能上说，爆发力就是这个系统能承受的最大压力，没准这个系统承受的压力很大。但过半个小时之间就挂掉了。耐力就是这个每系统长时间处于压力下的稳定性，这系统超级稳定，跑个几十年都不用重启服务器。那么整体协调性就是看系统有没系统瓶颈，需不需要进行系统调优。
在做性能测试时请忘掉分类
这里只是告诉在做性能测试时不要想这个测试是属于性能测试的哪一类呢？是并发性测呢？还是压力测试？
我们还拿上面的教练员选拔选手做例子。
记得我进校体队的时候，教练说让我跑两圈。然后，我就开始围绕着操场跑起来。你说教练让我跑两圈是想看我的什么能力？
1、双腿的考核，一个是步幅，就是步与步之间的距离。一个是频率，两腿交替的频率。如果你一步拉得很大的话，那么频率一定会下降。如果想提高频率的话，那么一定会影响到步幅的大小。
2、双臂的考核，肩膀是否放松，摆臂是否有力，双臂的摆动与双腿的摆动是否协调。
3、呼吸是否匀称，目前的速度可以跑几圈。
我只做了一项体育运行，就考核了我这么多内容。我们在做一个性能测试时也不局限在某一分类上，也可能我们的一个测试包含多个分类。
《web性能测试实战》：
么多类型的性能测试看起来很吓人，实际上它他们大多是密切相关的。例如，运行8个小时来测试系统是否可靠，而这个测试极有可能包含了可靠性能测、强度测试、并发测试、负载测试，等等。因此，在实施性能测试时决不能割裂它们的内部联系去进行，而应该分析它们之间的关系，以一种高效率的方式来设计性能测试。