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