在 LoadRunner 的运行场景中，有一个不大起眼的设置，可能经常会被很多人忽略，它就是 Pacing 。具体设置方式为： Run-Time settings à General à Pacing ，这个设置的功能从字面上就很容易理解，即在场景的两次迭代 (iteration) 之间，加入一个时间间隔（步进）。设置方法也很简单，这里就不赘述了，我在这里想说明的是，这个设置到底有什么作用？为什么要进行这个设置？说实话，虽然我在以前做过的一些性能测试中，偶尔会对这个步进值进行一些设置，但其实对它的真正含义和作用，我还并不十分清楚。
前段时间，我在对X银行招聘信息系统进行性能测试的时候，发现这个值的设置对于测试的结果有着很大的影响，很遗憾当时没有深入研究这个问题，而只是简单地认为它同脚本中的 thinktime 一样只是为了更真实地模拟实际情况而已。最近在网络上看到一篇题为《调整压力测试工具》的文章，读完之后，再用之前我的测试经历加以印证，真有种豁然开朗的感觉。以下就将我的一些体会与大家分享：
通常我们在谈到一个软件的“性能”的时候，首先想到的就是“响应时间”和“并发用户数”这两个概念。我们看到的性能需求经常都是这样定义的：
“要求系统支持 100 个并发用户”
看到这样的性能需求，我们往往会不假思索地就在测试场景中设置 100 个用户，让它们同时执行某一个测试脚本，然后观察其操作的响应时间，我们都是这样做的，不是吗？我在实际实施性能测试的过程中，也往往都是这样做的。可惜的是，我们中的大多数人很少去更深入地思考一下其中的奥妙，包括我自己。
事实上，评价一个软件系统的性能，可以从两个不同的视角去看待：客户端视角和服务器视角（也有人把它叫做用户视角和系统视角），与此相对应的，又可以引出两个让初学者很容易混淆的两个概念：“并发用户数”和“每秒请求数”。“并发用户数”是从客户端视角去定义的，而“每秒请求数”则是从服务器视角去定义的。
因此，上面所描述的做法的局限性就是，它反映的仅仅是客户端的视角。
对于这个世界上的很多事情，变换不同的角度去看它，往往可以有助于我们得到更正确的结论。现在，我们就转换一下角度，以服务器的视角来看看性能需求应该怎么样定义：
“要求系统的事务处理能力达到 100 个 / 秒” ( 这里为了理解的方便，假定在测试脚本中的一个事务仅仅包含一次请求 )
面对以这样方式提出的性能需求，在 LoadRunner 中，我们又该如何去设置它的并发用户数呢？千万不要想当然地以为设置了 100 个并发用户数，它就会每秒向服务器提交 100 个请求，这是两个不同的概念，因为 LoadRunner 模拟客户端向服务器发出请求，必须等待服务器对这个请求做出响应，并且客户端收到这个响应之后，才会重新发出新的请求，而服务器对请求的处理是需要一个时间的。我们换个说法，对于每个虚拟用户来说，它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间。而服务器对请求的处理时间是不可控的，如果我们想要在测试过程中维持一个稳定的每秒请求数（ RPS ），只有一个方法，那就是通过增加并发用户数的数量来达到这个目的。这个方法看起来似乎没有什么问题，如果我们在测试场景中只执行一次迭代的话。然而有经验的朋友都会知道，实际情况并不是这样，我们通常会对场景设置一个持续运行时间（duration，即多次迭代），通过多个事务 (transaction) 的取样平均值来保证测试结果的准确性。测试场景以迭代的方式进行，如果不设置步进值的话，那么对于每个虚拟用户来说，每一个发到服务器的请求得到响应之后，会马上发送下一次请求。同时，我们知道， LoadRunner 是以客户端的角度来定义“响应时间”的 ，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果。
因此，为了解决这个问题，我们可以在每两个请求之间插入一个间隔时间，这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间，从而提供更符合现实的响应时间。这就是我在文章开头所提到的 Pacing 这个值的作用。
最后再补充一句话：虽然性能测试通常都是从客户端活动的角度定义的，但是它们应该以服务器为中心的视角来看待。请注意这句话，理解它很重要，只有真正理解了这句话，你才会明白为什么我们一直强调做性能测试的时候要保证一个独立、干净的测试环境，以及一个稳定的网络，因为我们希望评价的是软件系统真正的性能，所以必须排除其它一切因素对系统性能造成的影响。
Kirk 在 Tuning your stress test harness 一文中提出的一个重要的观点就是“放慢速度，做得越多”。这其实是一种场景设计的思路，Kirk 提出这个的原因是他认为那些“不增加服务器负载的线程看起来会降低服务器的性能”，于是，Kirk 通过人为的方法来限制了 RPS（Request per Second）的值——这里我们要注意到的是，实际上 Kirk 是将 RPS 控制为小于 The Number of Concurrent Users 的值。以文中的例子来说，Kirk 是在 50 个并发用户的情况下，将 RPS 控制在了 9 个左右。这样的结果是什么？不知道你有没有注意到，在这篇文章中，Kirk 是以 RPS 作为指标衡量系统负载的，这种做法就算是所谓的“服务器视角”了吗？
我们知道对于一个给定的系统来说，在某个特定的环境和场景中，它的“最佳并发用户数(The Optimum Number of Concurrent Users)”是客观存在的——关于“最佳并发用户数”的概念可以参见我的《LoadRunner没有告诉你的之三——理发店模型》一文（http://www.cnblogs.com/jackei/archive/2006/11/20/565527.html）。当并发用户数大于这个“最佳”时，就会出现排队的情况。如果这个并发量一直持续，那么随着时间的流逝，队列也会越来越长，而越往后的请求在队列中等待的时间也越长，从性能测试工具中看到的响应时间也会越来越长。而这就是 Kirk 认为不合理的地方。但实际上是这样吗？当我们使用 LR 或者 JMeter 这类性能测试工具测试时，队列真的会越来越长吗？响应时间也会越来越长吗？
按照我的理解，Kirk所说的RPS，是以服务器为视角来看的每秒请求数，也就是每秒钟到达服务器端的请求，而不是从客户端发出请求的频率，我们知道这二者是会有差别的，否则的话，我们也用不着一直强调说做性能测试的时候一定要排除网络等因素的影响。同时这也是我看这篇文章获得最大的一个收获，因为他教我们用一个不同角度去看待问题。不过说实话，我也没有弄明白他把RPS设成9的原因，从他的描述和图中，我看不出这其中的对应关系。这个问题其实也让我想了好久，但他所说的RPS代表服务器视角，这一点我还是比较认同的，不知道你的意见如何，欢迎继续讨论。
当我们使用LR等工具的时候，队列确实不会越来越长，这个问题Kirk在文中也提到过了，他想告诉我们的是，由于我们所使用的工具的限制，导致了看似服务器在应付一种稳定状态的负载，其实却是个发散的队列（因为工具会在收到服务器响应后才会发出第二个请求），这也是他所指出的问题关键所在。但响应时间的确会越来越长的，因为当客户端收到服务器请求以后，如果我们没有设置延时，那么客户端会立即发出下一个请求，同时启动计时器，而此时如果服务器的资源已经满负荷，这个请求并不会进入排队队列，那么这个时间其实是多计算的，因此后面的这些请求的平均时间将越来越长，导致整个平均值不准确。
另外，这里我再提一个没有在我上面的文章中提到的一个问题，就是这个以“服务器视角”提出的性能需求应该是什么样子的，以前从来没有考虑过这个问题。
同样谢谢wufeiwufei的回复！我的BLOG是新开张，留言的人还不多，没想到一出手的就全是行家！^_^
你说的不错，kirk这篇文章的确更适合给性能优化工程师看，我不知道国外对于性能测试工程师和性能优化工程师是否有明确的定义和分工，但至少在国内，这二者的区别是不大的。到目前为止，我所接手过的性能测试工作，大部分也是同时承担这二者的角色的，因为客户或者项目经理，请你来做性能测试工作，不仅仅是要你指出系统存在什么性能问题，并且往往还希望你能告诉他们如何去解决。而且我也是这样来要求自己的，作为性能测试工程师，我认为我们也只有能够做到这一步，才更有成就感！:)
Jackei兄还是没有理解kirk的意思啊，kirk并不是一个测试工程师，他主要是从事java性能优化的，所以注定他必定是站在开发人员的角度去理解系统性能，直接的说他是为了发现程序中的性能问题而尽量避免因为硬件或是操作系统带来的影响。
我把你举的例子进一步假设：这是一个基于80端口的web项目（我们暂且叫做A程序），采用的windows nt操作系统，该操作系统对于80端口的连接限制为6个，A程序在运行过程中最多向cpu申请到4个线程。每个用户每次只发一个请求。
让我来按照我理解的kirk的思想分析你举的例子的：
1、让我们先来看看10个最佳并发用户数都在干些什么。按照单cpu来看，系统在一个时间片上只处理一个请求，也就是说只有1个用户被系统处理，那么其他的9个在干什么呢？按照假设，3个请求已经申请到线程，在等待cpu处理。6个请求在操作系统端，已经建立了连接，等待分配线程。
2、当20个并发数产生时，他们又在干什么呢？还是只有一个请求在被cpu处理，还是只有3个请求申请到线程，在等待cpu处理，仍然只有6个请求在操作系统端，已经建立了连接，等待分配线程，但是我们发现却多了10个请求在等待进入80端口，还没有建立连接。
3、那么kirk作为java程序优化工程师，什么是他关心的呢？有两点是他最关心的。a、每个请求的A程序处理时限；b、A程序对资源的占用和释放，对cpu线程申请是否合理。前一个很好理解，后一个我再做进一步解释，程序写的好坏，有很大一部分在于对资源的占用和释放，假设有个死循环在系统里，那么一旦申请到资源（cpu时间片），它始终不释放，必然导致cpu占用率一直是100％。再假设如果按照cpu的处理能力，A程序其实可以申请到4个时间片进行处理，但是实际上由于某个线程没有及时释放资源，或者对于一个需要长时间的请求没有sleep，导致只能申请到2个时间片，那就需要优化程序了。
通过上面的解释我们就可以发现其实只有4个请求的处理时间是kirk关心的。而其他的，那并不是程序优化应该关心的事情，你可以转交给系统工程师进行进一步的优化。
4、那么如何才能让这4个请求的处理时间更加准确了？很显然，由于loadrunner只能从发出请求就开始计算时间，因此如果前面的等待端口和等待分配线程的时间越长，那么得到的数据就越不准确。最合理的是根本就不要等待端口，最好每个请求都能直接建立并得到线程，进入cpu处理队列，当然因为我们并不知道cpu实际的队列长度，所以很难进行控制。
5、那么我们应该怎么作呢？首先我们找到最佳请求数，因为我们知道最佳请求数其实就是已经建立连接的6个请求加上分配到线程的3个请求，再加上1个正在处理的请求。然后我们逐步减少最佳请求数，其实也就是减少建立连接等待分配线程的请求数，随着逐步的减少，等待分配线程的时间也就减少，最终当我们减少到4个时，我们发现响应时间不再提高，我们也就找到了我们最关心的响应时间的最准确值。这个过程就是kirk说的从发散到平稳到收敛的过程。
6、我们还应该注意什么呢？因为我们无法把握cpu的处理时间，所以我们也不可能算好，第5个请求正好在第一个请求处理完成后发起，因此我们不可能准确的找到这个值。所以我在上个回复中说了，我们只有尽可能的接近收敛点，反复设置pacing值，好达到第5个请求到达时间接近第一个请求的释放时间，或是第6个请求到达时间不超过太多第一个请求释放时间。
7、什么是系统真正的性能，什么是程序A的最佳并发数？系统真正的性能并不等同于用户需求定义的性能，在kirk理解上，系统真正的性能是系统处理他应该去处理的事所得到的性能。如果请求建立连接的数量越多，那么必然耗损cpu时间，从而降低去处理A程序的效率，因此kirk认为我们应该减少并发数量，去测试真正的系统性能。而从这个角度理解，4个用户才是kirk认为的最佳并发数。
想到一个问题：如果我们以单位时间 1 秒来衡量系统的处理能力，发现每秒可以响应的请求数量是 10，也就是说每秒“流出”的是 10，那么是否可以认为最佳的请求数 RPS 也是 10 ？
也就是说，我们知道通常一个请求并不是只用一个 CPU 时间片就可以处理完的，而且单个 CPU 时间片是很短的。那么我们对于最佳请求数的评估是否要有一个时间单位做为基准？例如 1 秒。那么如果以 1 秒做为基准，是否最佳请求数同我之前提到的最佳并发用户数是同一个概念？
还是那句话，这应该是同一个问题，从两个不同的方面去理解。
我看过你写的《LoadRunner没有告诉你的》，里面对于“最佳并发用户数”的解释，我是赞同的，但“最佳请求数”这个概念，我相信很少有性能需求会这样去提的。所以我觉得还是像wufeiwufei所提到的那样，国内把测试工程师和性能优化工程师两个角色混在一起了，因此这二者之间的界限很模糊，在我做过的性能测试工作中，很多都是混在一起的，而偏偏客户和测试者都没有意识到这一点。
因此我是这样来理解的：如果是以用户的角度去测试，那之前谈到的最佳并发用户数的概念是没有错的，而一旦是涉及到性能瓶颈的定位、调优等，那还是需要从服务器的角度去测试。系统是否存在一个“最佳请求数”，并不是很重要，我们只需要保证在测试的过程中，能够使系统维持一个稳定的负载，保证测试结果准确、可信，不会有偏差就够了，也就是kirk说的，让服务器的队列处于稳定的而不是发散的状态。
我觉得可以这么理解，但是最佳并不是非常合适，虽然从大的方面讲增加请求数会在一定程度上增加cpu的负载，因而导致rps在某个阶段是有个最大的值，但实际上这和性能测试工程师理解的最佳有一定的差别的，性能测试工程师得到最佳并发用户数是更多的为了验证用户要求的性能目标或是为了以后的扩容有个量的了解，而从测试中得到这个rps更多的是为了发现问题进行优化，而不是为了达到某个目标，从这个角度来讲，rps没有最佳。
我一直认为rps对我们现在来说没有太大的意义，为什么这么说呢？
这是由于现在的性能测试过程决定的。现在的测试过程一般是：根据业务需求，设置目标，进行性能测试，获得基础数据－>根据数据对比业务需求，分解transcation，设置关注点－>再次测试 这样一个循环的过程。我们之所以认为有问题，是因为我们站在用户角度去进行测试，对于客户来说是不管是设备的问题还是软件的问题都是我们的问题，因此对于我们来说并不需要按照kirk的方式去追求rps，因为在这个过程中，我们可以把等待连接和分配进程的时间看成一个常量，而这个常量在所有的transcation中都是存在的。我们更多是去确定是那个trancation有问题，然后针对这个transcation进行优化。
而kirk是这样测试的（仅仅是我自己的看法），分别对软硬件进行性能测试－>软件寻找rps－>根据经验，判断是否合理－>然后进行优化。
看出这两个差别了吗？举个例子更好理解，项目A要求100个并发数下动态页面的响应时间不大于5秒，静态页面的响应时间不大于2秒。举出三种测试情况：
1、动态页面是6秒，静态页面是1秒。
2、动态页面是6秒，静态页面是3秒。
3、动态页面是4秒，静态页面是1秒。
只有在第二种情况下，我们才会去寻找是否是硬件的问题。而通常在这种情况下，其实我们已经要求更换硬件了。
而对kirk来说，三种情况并没什么区别，他一样要找到rps，然后根据技术标准来看是否需要对程序进行优化。
为什么会造成这种差别呢？我认为最重要的原因，国内没有积累，企业缺少规范，非常缺少性能优化工程师这类专业人才，只有用业务需求的标准来衡量，而没有真正的技术标准，没有技术标准，即使我们得到rps，你又如何分析出是否合理，是否需要优化呢？
以上只是我一家之言，而且我对操作系统层面的东西也不是很清楚，毕竟我只作过1年不到的开发。
严重同意wufeiwufei的观点，Kirk提出的问题，其实关键点在于他是从 “代码优化” 的角度来考虑问题的，他要的结果是“没有任何疑义的完全由于代码执行消耗的时间”，而不应该包括“队列等待时间”。
但对测试工程师来说，我们的任务是准确地知道真正的用户在使用这个系统时的性能感受，也就是完全的用户视角的“响应时间”，那当然应该包括全部的时间范围在内，Kirk提出的方法并不适用——所谓目的不同。
另外， 提出一点我的个人意见，上文所提到的RPS（或是TPS），我认为可以作为一个衡量系统压力的主要指标，在我看来，并发用户数和TPS都是在进行性能压力测试，或是衡量响应时间的依据，只有说“在XX用户数下，在XXTPS水平下”，响应时间才是有意义的。
Kirk确实是从“代码优化”的角度来考虑问题的。我不知道国外对于测试工程师和性能优化工程师这两个角色是否有严格的划分，但至少我自己在实际工作中，是没有分的，很多时候我都要身兼这两个角色，所以我觉得学会从两个角度来看待性能，是很有必要的，这也是我看Kirk文章的收获。另外，在我所做过的性能测试中，通常都会要求将后台服务器的一些无关进程、服务停掉，并且尽量使网络独立、或者保证带宽足够，这样的做法，本质上也是在确保使测试出来的性能结果尽量接近“实际的代码执行时间”。不知道各位在实际的工作中是怎样做的，这个问题也希望大家踊跃讨论。
关于关河老师最后提到的将RPS（TPS）作为衡量系统压力的指标，我也非常认同。
“在XX用户数下，在XXTPS水平下”，响应时间才是有意义的。 ”
我觉得准确得应该说 在xx用户数下，响应时间是多少，并单独加上tps值，和响应时间作为并列的性能指标。tps提交给开发组，响应时间记录进性能测试报告中。
我有几点问题，想请教关老师，jackei，xingxing等各位前辈同仁
1、我们都知道现在的性能测试，几乎都是根据预定的系统目标来衡量，而对代码的执行效率几乎没有任何评估，在这种情况下tps这个值到底还有多大意义。
2、如果我们真的关注代码的执行效率，那么通过loadrunner等性能测试工具得出tps值既烦琐而且得出的数值对定位问题几乎无多大的帮助，而据我所知行业中有针对java和.net的应用级的监控工具（例如：wily公司的introscope），从这个工具可以很轻松的观察到各个程序块的相对运行时间，随着并发用户数增加的，处理时间，占用资源的情况。那么kirk这篇文章又有多大的作用呢？
问题1：以我的实际经验来看，tps这个值通常是客户方关注得比较多，这是他们衡量一个应用系统性能好坏的一个重要标准。而对于项目组（程序代码的直接开发者）的性能定位、调优则几乎没有什么帮助。换句话说，这个值更多的用于“性能评测”，而不是“性能调优”。
问题2：你提到的wily公司的introscope主要是帮助我们来定位应用系统的性能问题，而kirk这篇文章则启发了我们，根据不同的测试目的应该有不同的测试策略。如果你的性能测试是为了定位程序中的性能问题，就应当尽可能地排除其它因素的干扰。
另：introscope这个工具我曾经看过wily公司的演示，感觉还可以，但我自己试用的时候却没配置成功。不知道你有是否对它有研究？
不好意思，写错了，不是tps，我的意思是rps，你可能没有明白我的意思，我是说我们现在的测试立足点基本就是站在客户方，而调优仅仅是在达不到客户方要求的情况下才进行的，因此我觉得过分追捧kirk的理论对我们现实的测试工作没有任何帮助，因为即使我们利用这个理论去找到最接近系统处理能力的rps，但是实际上也无助于我们进行性能调优（因为我们几乎无法对这个值进行评测）。
至于introscope的设置不好搞，我个人认为也因而导致他的推广的不力，我自己并没有单独成功配置过，基本上都需要他们的支持人员帮助才能搞定（通常还要花很长时间）。
非常同意wufeiwufei的观点，我们现在的性能测试相当于验收测试，在功能差不多稳定的情况下，验证系统是否满足需求方提出的各个性能指标。而Kirk跟我们进行的不是一个层面的工作。他不管用户需求，只考虑自己的程序是否还有调优的空间。
有关于RPS说几句。在我们公司的测试中，性能指标不是由需求方提出来的，而是我们测试人员根据线上的日志分析出出来的。一般关键的指标是2点：TPS和响应时间。而并发用户数我们是不关注的。跟我们系统本身的特点有关。我们做的是网络支付行业，一般来说，如果用户不提交请求，只浏览页面，对于系统造成的压力我们是忽略的。
TPS是测试工程师分析线上的日志情况，计算出每天的高峰请求数。响应时间则是按照行业内的2/5/8原则。
按照这样的情况设计的测试场景[测试工具是LoadRunner]，是基于目标的场景，即设置系统每秒要达到的TPS，至于并发用户数是工具根据响应时间自动计算出来的。
在这种情况下，我在想Pacing的设置可能没有太多的关系。因为我们的测试本身就是以服务器的角度来考虑的。不知道这样的想法是否正确，还请各位高手指点。
对槛外人说的,网络支付这个特定的性能测试来说,一些人只浏览页面不提交对服务器的压力就可以忽略.
----对于以上一个观点我有疑问,这些人浏览页面不需要占用服务器内存或影响CPU的效率么,要知道浏览页面的用户值N可能是一个很大的数.
我想请大家给个准确的意见.比如在考虑网上支付混合场景性能测试的时候,一个脚本做付款;一个脚本做注册;一个脚本做查询,还需要不需要设置一个脚本就是模拟那些只浏览不提交的情况呢?
二,
我想试着回答下槛外人的问题.
我想你没理解他们使用pacing的意义在哪里.我觉的前面几个大侠已经讨论的很清楚.他们是用PACING,在忽略硬件的环境下,来尽量找出代码的RPS这个值.
而代码的RPS这个值对于我们现情况的性能测试工程师来说,是没有实际意义的.( 这点楼上大侠也说的清楚.) 代码的RPS是针对代码的性能调优的.而我们现阶段的性能测试工程师是做不到这一点的.我们现阶段的性能测试工程师,测试的是硬件环境+软件环境+网络条件下的性能的.
而硬件环境+软件环境+网络条件,也更接近于用户的实际环境.所以我们现在测试没必要去设置PACING.
-----不知道,我这样的理解对不对。。
第一个问题：我是基于一种假设，在我们的支付平台中，主要的压力来自于系统处理用户提交的涉及数据库的请求，比如说付款、查询交易等等。而那些只浏览不提交的页面，在大并发的用户访问下，性能是受限于网络流量的。这些系统管理员可以做出当前的昨天可以支持的用户数。所以我们忽略它。在实际的测试过程中，如何确定是否要对一个功能进行性能测试，是根据其实现过程分析它给系统带来的性能消耗来决定的。假设说一个静态页面，里面就简单显示了几张图片，那么其实它的消耗只在带宽上，根本没有必要做性能测试的。
第二个问题：对于性能测试的建模，目前有2种方式。一种是基于用户（客户端）的，另一种是基于系统（服务器）的。2种方式各有优缺点。而我们目前选择的是第二种。这种建模方式不关注客户端的操作，只关心系统在多大的压力(通过设置TPS)下工作。 而Pacing按照我的理解是客户端的设置，它控制的是虚拟用户。
对于以上的第一个问题，我同意槛外人“如何确定是否要对一个功能进行性能测试，是根据其实现过程分析它给系统带来的性能消耗来决定的。”的说法。
至于第二个问题，Pacing设置的确是客户端的设置，通过控制虚拟用户发送的请求频率来对服务器端造成压力。Pacing究竟对服务器的性能结果是否有影响？以及如何影响的？在原文中已经说得很清楚，当发送的请求频率在服务器处理能力范围内（队列处于收敛和稳定状态）时，而当发送的请求达到一定的频率，超过了服务器处理的能力（队列处于发散状态）时，是会对测试结果产生影响的。
thinktime是指在测试的过程中，每一步操作中间的思考时间（停顿）。
pacing是指在测试过程中，每两次迭代（或称循环）间的停顿。
