文档文库
手机版
投诉建议
热门搜索： 心得体会 演讲稿 思想汇报
首页 > 性能测试方法及分析方法

性能测试方法及分析方法

发布时间：2016-10-14   来源：文档文库   
小 中 大
字号：
手机查看
性能测试方法及分析方法
一、 性能测试简介
1.1 什么是软件性能
一般来说，性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软件产品的一种特性，可以用时间来进行度量。
性能的及时性用响应时间或者吞吐量来衡量。响应时间是对请求作出响应所需要的时间。
对于单个事务，响应时间就是完成事务所需的时间；对于用户任务，响应时间体现为端到端的时间。比如，“用户单击OK按钮后2秒内收到结果”就是一个对用户任务响应时间的描述，具体到这个用户任务中，可能有多个具体的事务需要完成，每个事务都有其单独的响应时间。
对交互式的应用（例如典型的Web应用）来说，我们一般以用户感受到的响应时间来描述系统的性能，而对非交互式应用（嵌入式系统或是银行等的业务处理系统）而言，响应时间是指系统对事件产生响应所需要的时间。
通常，对软件性能的关注是多个层面的：用户关注软件性能，管理员关注软件性能，产品的开发人员也关注软件性能，下面将从3个不同层面来对软件性能进行阐述。
1.1.1 用户视角的软件性能
从用户的角度来说，软件性能就是软件对用户操作的响应时间。说得更明确一点，对用户来说，当用户单击一个按钮、发出一条指令或是在Web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。图1.1以一个Web系统为例，说明了用户的这种印象。
1 / 28


发出请求请求应用服务器DB服务器用户用户感受到响应返回数据应用界面呈现呈现时间系统响应时间
图1.1 Web系统的响应
必须要说明的是，用户所体会到的“响应时间”既有客观的成分，也有主观的成分。例如，用户执行了某个操作，该操作返回大量数据，从客观的角度来说，事务的结束应该是系统返回所有的数据，响应时间应该是从用户操作开始到所有数据返回完成的整个耗时；但从用户的主观感知来说，如果采用一种优化的数据呈现策略，当少部分数据返回之后就立刻将数据呈现在用户面前，则用户感受到的响应时间就会远远小于实际的事务响应时间（顺便说一下，这种技巧是在C/S结构的管理系统中开发人员常用的一种技巧）。
关于响应时间的进一步讨论请见1.2.1节对“响应时间”的解释。
1.1.2 管理员视角的软件性能
从管理员的角度来看，软件系统的性能首先表现在系统的响应时间上，这一点和用户视角是一样的。但管理员是一种特殊的用户，和一般用户相比，除了会关注一般用户的体验之外，他还会关心和系统状态相关的信息。例如，管理员已经知道，在并发用户数为100时，A业务的响应时间为8秒，那么此时的系统状态如何呢？服务器的CPU使用是不是已经达到了最大值？是否还有可用的内存？应用服务器的状态如何？我们设置的JVM可用内存是否足够？数据库的状况如何？是否还需要进行一些调整？这些问题普通的用户并不关心，因为这不在他们的体验范围之内；但对管理员来说，要保证系统的稳定运行和持续的良好性能，就必须关心这些问题。
另一方面，管理员还会想要知道系统具有多大的可扩展性，处理并发的能力如何；而且，管理员还会希望知道系统可能的最大容量是什么，系统可能的性能瓶颈在哪里，通过更换哪些设备或是进行哪些扩展能够提高系统性能，了解这些情况，管理员才能根据系统的用户状况制定管理措施，在系统出现计划之外的用户增长等紧急情况的时候能够立即制定相应措施，进行迅速的处理；此外，管理员可能还会关心系统在长时间的运行中是否足够稳定，是否能够不间断地提供业务服务等。
2 / 28


因此，从管理员的视角来看，软件性能绝对不仅仅是应用的响应时间这么一个简单的问题。
表1-1给出了管理员关注的部分性能相关问题的列表。
表1-1 管理员关注的部分性能相关问题
管理员关心的问题
服务器的资源使用状况合理吗
应用服务器和数据库的资源使用状况合理吗 系统是否能够实现扩展
系统最多能支持多少用户的访问？系统最大的业务处理系统容量
量是多少
系统性能可能的瓶颈在哪里 更换哪些设备能够提高系统性能 系统能否支持7×24小时的业务访问
系统可扩展性 系统可扩展性 系统稳定性 软件性能描述 资源利用率 资源利用率 系统可扩展性
1.1.3开发视角的软件性能
从开发人员的角度来说，对软件性能的关注就更加深入了。开发人员会关心主要的用户感受——响应时间，因为这毕竟是用户的直接体验；另外，开发人员也会关心系统的扩展性等管理员关心的内容，因为这些也是产品需要面向的用户（特殊的用户）。但对开发人员来说，其最想知道的是“如何通过调整设计和代码实现，或是如何通过调整系统设置等方法提高软件的性能表现”，和“如何发现并解决软件设计和开发过程中产生的由于多用户访问引起的缺陷”，因此，其最关注的是使性能表现不佳的因素和由于大量用户访问引发的软件故障，也就是我们通常所说的“性能瓶颈”和系统中存在的在大量用户访问时表现出来的缺陷。
举例来说，对于一个没有达到预期性能规划的应用，开发人员最想知道的是，这个糟糕的性能表现究竟是由于系统架构选择的不合理还是由于代码实现的问题引起？由于数据库设计的问题引起？抑或是由于系统的运行环境引发？
或者，对于一个即将发布到现场给用户使用的应用，开发人员可能会想要知道当大量用户访问这个系统时，系统会不会出现某些故障，例如，是否存在由于资源竞争引起的挂起？是否存在由于内存处理等问题引起的系统故障？
因此，对开发人员来说，单纯获知系统性能“好”或者“不好”的评价并没有太大的意 3 / 28


义，他们更想知道的是“哪些地方是引起不好的性能表现的根源”或是“哪里可能存在故障发生的可能”。
表1-2给出了开发视角的软件性能关注内容。
表1-2 开发人员关注的性能问题
开发人员关心的问题
架构设计是否合理 数据库设计是否存在问题 代码是否存在性能方面的问题 系统中是否有不合理的内存使用方式 系统中是否存在不合理的线程同步方式 系统中是否存在不合理的资源竞争
问题所属层次 系统架构 数据库设计
代码 代码 设计与代码 设计与代码
1.1.4总结
以上我们描述了3个不同层面上的软件性能关注点，由此可见，不同的对象对软件系统性能的关注是有着显著的差异的。从项目管理的角度，以我们的系统干系人来分析，大部分用户对性能的理解属于“用户视角”，项目的维护人员或是用户方的项目经理一般会从“管理员视角”来看待软件性能的问题，而项目的创建者——开发人员（包括设计人员）自然就是从“开发视角”来关注软件性能了。
因此，对软件性能测试来说，在不同的层面上要求我们关注不同的内容：从直接体验的用户的角度来说，表现为软件系统对用户操作的响应时间；在系统或是管理员的关注层面，我们还需要从软件的性能表现分析系统的可扩展性、并发能力等指标；最后，从最贴近软件的创建者——开发人员的角度来说，还需要为软件性能问题进行定位，了解性能的制约因素和引起性能问题的关键原因。
1.2 软件性能的几个术语
接触过软件性能测试的人，会经常听到这样一些词汇：响应时间、并发用户数、吞吐量、性能计数器，在使用性能测试工具进行测试时，还会接触到“思考时间（Think Time）”的概念，那么，这些术语的确切含义究竟是什么呢？
4 / 28


本节重点介绍以上的各个术语。
1.2.1 响应时间
在1.1节和1.1.1节中都提到了“响应时间”的概念，响应时间是“对请求作出响应所需要的时间”，而且，我们把响应时间作为用户视角的软件性能的主要体现。
图1.1将用户所感受到的软件性能（响应时间）划分为“呈现时间”和“系统响应时间”两个部分，其中“呈现时间”取决于数据在被客户端收到响应数据后呈现页面所消耗的时间，例如，对一个Web应用，呈现时间就是浏览器接收到数据后用户把数据呈现出来的时间；而“系统响应时间”指应用系统从请求发出开始到客户端接收到数据所消耗的时间。在一般的性能测试中，我们并不关注“呈现时间”，这是因为呈现时间在很大程度上取决于客户端的表现，例如，一台内存不足的客户端机器在处理复杂页面的时候，其呈现时间可能就很长，而这并不能说明整个系统的性能。在后续的软件性能测试的讨论中，我们不会区分“系统响应时间”和“响应时间”，直接把这里的“系统响应时间”等同于“响应时间”。
响应时间可以被进一步分解。图1.2描述了一个Web应用的页面响应时间的构成。从图中可以看到，页面的响应时间可被分解为“网络传输时间”（N1+N2+N3+N4）和“应用延迟时间”（A1+A2+A3），而“应用延迟时间”又可以分解为“数据库延迟时间”（A2）和“应用服务器延迟时间”（A1+A3）。之所以要对响应时间进行这些分解，主要目的是为了能更好定位性能瓶颈的所在。在后续的实例讨论中，读者将会看到如何应用这些响应时间的分解进行性能问题的定位。

图1.2 Web应用的页面响应时间分解
关于响应时间，要特别说明的一点是，对客户来说，该值是否能够被接受是带有一定的用户主观色彩，也就是说，响应时间的“长”和“短”没有绝对的区别。
例如，对一个电子商务网站来说，在美国和欧洲，一个普遍被接受的响应时间标准为2/5/10秒，也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力的”，在5秒之内响应客户被认为是“比较不错的”，而10秒是客户能接受的响应的上限。
但考虑一个税务报账系统，该系统的用户每月使用一次该系统，一次花费2小时以上进 5 / 28


行数据的录入，当用户单击“提交”按钮后，即使系统在20分钟后才给出“处理成功”的消息，用户仍然不会认为该系统的响应时间不能接受——毕竟，相对于一个月才进行一次的操作来说，20分钟确实是一个可以接受的等待时间。
因此，在进行性能测试时，“合理的响应时间”取决于实际的用户需求，而不能依据测试人员自己的设想来决定。
1.2.2 并发用户数
在阐述这个术语之前，先来看看为什么在性能测试中需要关注这个“并发用户数”。 首先，如果性能测试的目标是验证当前系统能否支持现有用户的访问，最好的办法就是弄清楚会有多少用户会在同一个时间段内访问被测试的系统，如果使用性能测试工具模拟出与系统的访问用户数相同的用户，并模拟用户的行为，那得到的测试结果就能够真实反映实际用户访问时的系统性能表现，这样一来，也就能够通过性能测试了解到当系统处于实际用户访问时，会具有怎样的性能表现。这里提到的在同一个时间段内访问系统的用户数量，也就是我们说的并发用户数的一个概念，这种并发的概念通常在性能测试（Performance Testing）方法中使用，用于从业务的角度模拟真实的用户访问，体现的是业务并发用户数。
如果抛开业务的层面，仅从服务器端承受的压力来考虑，那么，对C/S或是B/S结构的应用来说，系统的性能表现毫无疑问地主要由“服务端”决定。在什么时候“服务端”会承受最大的压力，或者说，在什么时候“服务端”表现为最差的性能呢？毫无疑问，肯定是在大量用户同时对这个系统进行访问的时候。为了说明这个“同时”，参见图1.3。


图1.3 用排球击打墙面
图1.3用“排球击打墙面”说明这种“同时”，毫无疑问，越多的球同时击打到墙面，墙面承受的压力也就越大。如果把击打排球的人看成是系统的使用者，墙壁代表了我们可怜的服务端，显然，当越多的用户同时使用系统，系统承受的压力越大，系统的性能表现也就越差，而且，此时很可能出现由于用户的同时访问导致的资源争用等问题。我们在这里提到 6 / 28


了“并发用户数”的另一个概念，该概念不从业务角度出发，而是从服务端承受的压力出发，描述的是同时向客户端发出请求的客户，该概念一般结合并发测试（Concurrency Testing）使用，体现的是服务端承受的最大并发访问数。
下面我们用一个更接近实际的例子来说明这两个并发概念之间的不同。 图1.4所示是实际应用系统的演示。
应用界面服务器VUVU2VU3VUGVUG
图1.4 实际应用系统
对服务端来说，每个用户和服务端的交互都是离散的。如果仅考虑一个单独的用户对系统的使用，过程大致如下：用户每隔一段时间向服务端发送一个请求或是命令，服务端按照用户的请求执行某些操作，然后将结果返回给用户。
从用户的角度来看，在一个相当长的时间段内（例如1天），都会有基本固定数量的使用者使用该系统，虽然每个使用者的行为不同，但从业务的角度来说，如果所有这些用户的操作都没有遇到性能障碍，则可以说该系统能够承受该数量的并发用户访问，这里的并发概念就是前面讨论的业务并发用户数。
然而，如果考虑整个系统运行过程中服务器所承受的压力，情况就会不同了：在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上，都有一个“同时向服务端发送请求的客户数”，这个就是所称的服务端承受的最大并发访问数。如果能找到运行过程中可能出现的最大可能的服务端承受的最大并发访问数，则在该用户数下，服务器承受的压力最大，资源承受的压力也最大，在这种状态下，可以考虑通过并发测试（Concurrency Testing）发现系统中存在的并发引起的资源争用等问题。
在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户人数”，下面用一个实际的例子来说明它们之间的差别。
假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量计数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人 7 / 28


在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？
根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在饶有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。
那么，该系统的服务端承受的最大并发访问数是多少呢？这个取决于业务并发用户数和业务场景，一般可以通过对服务器日志的分析得到。
在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。
那么，究竟应该如何获得测试人员关心的并发用户数的具体数值呢？ 下面给出了一些用于估算并发用户数的公式。
CnL （1）
TˆC3C （2）
C在公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。例如，对一个典型的OA应用，考察的时间段长度应该为8小时的工作时间。
iˆ指并发用户数的峰值，C就公式（2）则给出了并发用户数峰值的计算方式，其中，C是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
下面根据上述给出的方法进行实例计算。
实例：假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在 8 / 28


一天的时间内，用户只在8小时内使用该系统。 则根据公式（1）和公式（2），可以得到：
C=400×4/8=200 ˆ200+3×200=242 C当然，这是种可行的方法，但仔细考究起来，其并不是惟一，甚至说不上是最精确的方法，因为在公式中仍然需要估算“平均用户数”和“login session的长度”，而要精确估算这两个值并不容易。另外，考虑到用户的业务操作存在一定的时间集中性（也就是说，用户对系统业务的访问往往不是平均分布在整个考察时间段内，而是相对集中地分布在某几个时间段内），采用公式（1）和公式（2）进行计算仍然存在一定的偏差。
我们给出对该公式使用的一些建议，遵循这些建议，可以更精确地计算得到并发用户数： （1）以更细的时间粒度进行考察：例如，可以设定1个小时为考察时间的粒度，对一个典型的OA系统，将一天的上班时间划分为8个区间，这样可以解决前面提到的业务操作存在的时间集中性的问题。
（2）考虑典型的业务模式：不同的应用有不同的业务模式，例如，一个内部系统一般在上班开始后的30分钟至1个小时集中出现用户的登录；一个账务系统在每月的结账日前几天会比较繁忙；一个门户网站在重大消息发布的前后会有访问高峰；一个旅游的网站在节假日前夕会有大量用户的访问……因此，在考虑计算并发用户数时，可以结合应用的业务模式，多考虑一些可能发生的场景，基于这些场景进行估算。
除了这种介绍的方法之外，对于企业内部使用的Web系统来说，一个更一般的（当然精度更差）经验公式是：
Cn10 （3） ˆrC （4）
C也就是说，用每天访问系统用户数的10%作为平均的并发用户数，并发用户数的最大值由并发用户数乘上一个调整因子r得到，r的取值一般为2～3。
公式（3）和公式（4）可以在要求不太严格的性能测试，或是只有很少数据支持分析的性能测试中使用。
在本节的前面部分提到了“日志分析”方法。所谓“日志分析”方法是指通过对应用服务器的日志进行分析，从而了解系统用户的使用状态，从日志中计算出“服务器承受的最大并发用户访问数”数据。这种方式得到的数据准确度和可信度都比较高，对于Internet应 9 / 28


用等无法估计用户数量和用户行为模式的应用，这种方式最为可信。
1.2.3 吞吐量
吞吐量是指“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力。一般来说，吞吐量用请求数/秒或是页面数/秒来衡量，从业务的角度，吞吐量也可以用访问人数/天或是处理的业务数/小时等单位来衡量。当然，从网络的角度来说，也可以用字节数/天来考察网络流量。
例如，对一个Web应用系统来说，从系统的处理能力考虑，可以以页面数/秒作为吞吐量的标准；对一个银行的业务前台系统来说，可以以其处理的业务数/小时作为吞吐量的标准。
在本章的开始部分，已经讨论过，对于交互式应用，用户直接的体验是“响应时间”，通过“并发用户数”和“响应时间”可以确定系统的性能规划；但对于非交互式应用，用“吞吐量”来描述我们对系统性能的期望可能更加合理。
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力。在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力；另外，在性能调优的过程中，吞吐量指标也有重要的价值，例如，Empirix公司在报告中声称，在他们所发现的性能问题中，有80%是因为吞吐量的限制导致的。
在对Web系统的性能测试过程中，吞吐量主要以请求数（单击数）/秒、页面数/秒或是字节数/秒来体现，吞吐量指标可以在两个方面发挥作用：
（1）用于协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标：在设计性能测试场景时，吞吐量可被用于协助设计性能测试场景，根据估算的吞吐量数据，可以对应到测试场景的事务发生频率、事务发生次数等；另外，在测试完成后，根据实际的吞吐量可以衡量测试是否达到了预期的目标。
（2）用于协助分析性能瓶颈：吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对性地对吞吐量设计测试，可以协助尽快定位到性能瓶颈所在位置。例如，RBI（Rapid Bottleneck Identify）方法就主要通过吞吐量测试发现性能 瓶颈。
以不同方式表达的吞吐量可以说明不同层次的问题。例如，以字节数/秒方式表示的吞吐量主要受网络基础设施、服务器架构、应用服务器制约；以单击数/秒方式表示的吞吐量主要受应用服务器和应用代码的制约。
10 / 28


作为性能测试时的主要关注指标，吞吐量和并发用户数之间存在一定的联系。在没有遇到性能瓶颈的时候，吞吐量可以采用如下公式计算：
FNvuR （5）
T其中，F表示吞吐量；Nvu表示VU（Virtuae User，虚拟用户）的个数；R表示每个VU发出的请求（单击）数量；T表示性能测试所用的时间。但如果遇到了性能瓶颈，此时吞吐量和VU数量之间就不再符合公式（5）给出的关系。
常用于分析吞吐量的图形是“吞吐量——VU数量”的关联图。图1.5给出了两个“吞吐量——VU数量”关联图的示例。
从图中可以看到，吞吐量在VU数量增长到一定程度的时候产生了性能 瓶颈。 最后，必须要说明的是，虽然吞吐量指标可被看作是系统承受压力的体现，但在不同并发用户数量的情况下，对同一个系统施加相同的吞吐量压力，很可能会得到不同的测试结果。本文给出了一个示例。

图1.5 “吞吐量——VU数量”关联图示例
对同一个应用进行两次不同的性能测试，测试A采用100个并发，每个VU间隔1秒发出一个请求；测试B采用1000个并发，每个VU间隔10秒发出一个请求；对测试A，测试时的吞吐量（页/秒）为100×1/1=100；对测试B来说，吞吐量（页/秒）为1000×1/10=100，仍然是100。但从测试结果来看，执行测试A时，应用在50页/秒出现性能瓶颈，而测试B在25页/秒出现性能瓶颈。
1.2.4 性能计数器
性能计数器（Counter）是描述服务器或操作系统性能的一些数据指标。例如，对Windows系统来说，使用内存数（Memory In Usage），进程时间（Total Process Time）等都是常见的计数器。
计数器在性能测试中发挥着“监控和分析”的关键作用，尤其是在分析系统的可扩展性、进行性能瓶颈的定位时，对计数器取值的分析非常关键。但必须说明的是，单一的性能计数 11 / 28


器只能体现系统性能的某一个方面，对性能测试结果的分析必须基于多个不同的计数器。
与性能计数器相关的另一个术语是“资源利用率”。该术语指的是系统各种资源的使用状况。为了方便比较，一般用“资源的实际使用/总的资源可用量”形成资源利用率的数据，用以进行各种资源使用的比较。
例如，我们会说到，“某某系统在承受10000用户的并发访问时，Web服务器的CPU占用率为68%，平均的内存占用率为55%”，这其中，68%和55%就是典型的资源利用率的数值。
在性能测试中常用资源利用率进行横向的对比，例如，在进行测试时会发现，资源A的使用率达到了接近100%的数值，而其他的资源利用率都处于比较低的水平，则可以很清楚地知道，资源A就很有可能是系统的一个性能瓶颈。当然，资源利用率在通常的情况下需要结合响应时间变化曲线、系统负载曲线等各种指标进行分析。
性能计数器是性能测试分析的主要参考值，本书的第3章对其进行了详细的解释说明，并说明了如何利用这些计数器分析系统性能瓶颈。
1.2.5 思考时间
思考时间（Think Time），也被称为“休眠时间”，从业务的角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。前面已经讨论过，对交互式应用来说，用户在使用系统时，不大可能持续不断地发出请求，更一般的模式应该是用户在发出一个请求后，等待一段时间，再发出下一个请求。
因此，从自动化测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个操作之间等待一段时间，体现在脚本中，具体而言，就是在操作之间放置一个Think的函数，使得脚本在执行两个操作之间等待一段时间。
在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。不同的测试工具提供了不同的函数或者方法来实现思考时间，本书附录A中对思考时间进行了的详细描述，另外，本书实践篇也有一些使用思考时间的实际 例子。
在实际的测试中，设置多长的思考时间最为合理是许多性能测试工程师关心的问题。其实，思考时间与迭代次数、并发用户数和吞吐量之间存在一定的关系。
公式（5）说明吞吐量是VU数量Nvu、每个用户发出请求数R和时间T的函数，而其中的R又可以用时间T和用户的思考时间Ts来计算：
RT （6） Ts 12 / 28


用公式（5）和公式（6）进行化简运算可得，吞吐量与Nvu成正比，而与Ts成反比。 不少性能测试工程师在实际的应用中都对如何给定合适的思考时间存在疑问，那么，在具体的测试实践中，究竟该怎样选择合适的思考时间呢？下面给出一个计算思考时间的一般步骤：
1．首先计算出系统的并发用户数； 2．统计出系统平均的吞吐量；
3．统计出平均每个用户发出的请求数量； 4．根据公式（6）计算出思考时间。
当然，为了让性能测试场景更加符合实际情况，可以考虑以步骤4计算得出的思考时间为基准，让实际的思考时间在一定幅度内随机变动。LoadRunner和Segue Silk Performer等工具都支持以这种方式设置思考时间。
最后要说明的是“0思考时间”。有些文章建议在测试中使用“0”作为思考时间，以给系统更大的压力。在本人的实际性能测试过程中，对于交互式的应用系统，很少遇到这样的要求。因为从业务的角度考虑，思考时间用于更真实地模拟用户操作，设置思考时间为0，基本上不具有实际的业务含义。
但在非交互式应用的性能测试过程中，有时候确实会将思考时间设置为0，这时候是模拟一种尽可能大的压力，研究系统在巨大压力下的表现。
可以说，如果测试的目的是为了“验证应用系统具有预期的能力”（也就是所说的“能力验证”的应用领域），就应该尽量模拟用户在使用业务时的真实思考时间；如果目的是进行更一般的研究，例如“了解系统在压力下的性能水平”或是“了解系统承受压力的能力”（也就是所说的“规划能力”的应用领域），则可以采用0思考时间。
二、 性能测试方法论与方法
“没有规矩，不成方圆”。对性能测试来说，如果没有合适的方法论指导，性能测试很容易成为一种随意的测试行为，而随意进行的性能测试很难取得实际的作用和预期的效果，因此本章将简单介绍几种常见的性能测试过程和方法，并着重介绍常用的性能测试方法。
13 / 28


2.1 性能测试方法论
2.1.1 SEI负载测试计划过程
SEI负载测试计划过程（SEI Load Testing Planning Process）是一个关注于负载测试计划的方法，其目标是产生“清晰、易理解、可验证的负载测试计划”。SEI负载测试计划过程包括6个关注的区域（Area）：目标、用户、用例、生产环境、测试环境和测试场景。
SEI负载测试计划过程将以上述6个区域作为负载测试计划需要重点关注和考虑的内容，其重点关注以下几个方面的内容：
1．生产环境与测试环境的不同：由于负载测试环境与实际的生产环境存在一定的差异，因此，在测试环境上对应用系统进行的负载测试结果很可能不能准确反映该应用系统在生产环境上的实际性能表现，为了规避这个风险，必须仔细设计测试环境。
2．用户分析：用户是对被测应用系统性能表现最关注和受影响最大的对象，因此，必须通过对用户行为进行分析，依据用户行为模型建立用例和场景。
3．用例：用例是用户使用某种顺序和操作方式对业务过程进行实现的过程，对负载测试来说，用例的作用主要在于分析和分解出关键的业务，判断每个业务发生的频度、业务出现性能问题的风险等。
从SEI负载测试计划过程的描述中可以看到，SEI负载测试计划过程给出了负载测试需要关注的重点区域，但严格来说，其并不能被称为具体的方法论，因为其仅仅给出了对测试计划过程的一些关注内容，而没有能够形成实际的可操作的过程。
同功能测试一样，性能测试也必须经历测试需求、测试设计、测试执行、测试分析等阶段，但由于性能测试自身的特殊性（例如，需要引入工具，分析阶段相对重要），性能测试过程又不能完全套用功能测试过程。
SEI负载测试计划过程在负载测试需要关注的具体内容上提供了参考，但其并不是一个完整的测试过程。
2.1.2 RBI方法
RBI（Rapid Bottleneck Identify）方法是Empirix公司提出的一种用于快速识别系统性能瓶颈的方法。该方法基于以下一些事实：
1. 发现的80%系统的性能瓶颈都由吞吐量制约；
14 / 28


2. 并发用户数和吞吐量瓶颈之间存在一定的关联； 3. 采用吞吐量测试可以更快速定位问题。
RBI方法首先访问服务器上的“小页面”和“简单应用”，从应用服务器、网络等基础的层次上了解系统吞吐量表现；其次选择不同的场景，设定不同的并发用户数，使其吞吐量保持基本一致的增长趋势，通过不断增加并发用户数和吞吐量，观察系统的性能表现。
在确定具体的性能瓶颈时，RBI将性能瓶颈的定位按照一种“自上而下”的分析方式进行分析，首先确定是由并发还是由吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器和代码本身4个环节确定系统性能具体的瓶颈。
RBI方法在性能瓶颈的定位过程中能发挥良好的作用，其对性能分析和瓶颈定位的方法值得借鉴，但其也不是完整的性能测试过程。
2.1.3 性能下降曲线分析法
性能下降曲线实际上描述的是性能随用户数增长而出现下降趋势的曲线。而这里所说的“性能”可以是响应时间，也可以是吞吐量或是单击数/秒的数据。当然，一般来说，“性能”主要是指响应时间。
图1.6给出了一个“响应时间下降曲线”的示例。

图1.6 一条典型的响应时间性能下降曲线示例
从图1.6可以看到，一条曲线可以分为以下几个部分：
（1）单用户区域——对系统的一个单用户的响应时间。这对建立性能的参考值很有作用。 （2）性能平坦区——在不进行更多性能调优情况下所能期望达到的最佳性能。这个区域可被用作基线或是benchmark。
（3）压力区域——应用“轻微下降”的地方。典型的、最大的建议用户负载是压力区域 15 / 28


的开始。
（4）性能拐点——性能开始“急剧下降”的点。
这几个区域实际上明确标识了系统性能最优秀的区间，系统性能开始变坏的区间，以及系统性能出现急剧下降的点。对性能测试来说，找到这些区间和拐点，也就可以找到性能瓶颈产生的地方。
因此，对性能下降曲线分析法来说，主要关注的是性能下降曲线上的各个区间和相应的拐点，通过识别不同的区间和拐点，从而为性能瓶颈识别和性能调优提供依据。
2.1.4 LoadRunner的性能测试过程
图1.7给出了LoadRunner的性能测试过程。LoadRunner将性能测试过程分为计划测试、测试设计、创建VU脚本、创建测试场景、运行测试场景和分析结果6个步骤。
第一步计划测试第二步测试设计第三步创建 VU
脚本第四步创建测试场景第五步运行测试场景第六步分析结果
图1.7 LoadRunner的性能测试过程
计划测试阶段主要进行测试需求的收集、典型场景的确定；测试设计阶段主要进行测试用例的设计；创建VU脚本阶段主要根据设计的用例创建脚本；创建测试场景阶段主要进行测试场景的设计和设置，包括监控指标的设定；运行测试场景阶段对已创建的测试场景进行执行，收集相应数据；分析结果阶段主要进行结果分析和报告工作。
LoadRunner提供的这个性能测试过程已经涵盖了性能测试工作的大部分内容，但由于该过程过于紧密地与LoadRunner工具集成，没有兼顾使用其他工具，或是用户自行设计工具的需求，也不能被称为是一个普适性的测试过程。
16 / 28


另外，LoadRunner提供的该性能测试过程并未对计划测试阶段、测试设计阶段的具体行为、方法和目的进行详细描述，因此该方法最多只能被称为“使用LoadRunner进行测试的过程”，而不是一个适应性广泛的性能测试过程。
2.1.5 Segue提供的性能测试过程
图1.8给出了Segue公司Silk Performer提供的性能测试过程。该性能测试过程与Performance Testing Lifecycle描述的一致，是一个不断try-check的过程。
Silk Performer提供的性能测试过程从确定性能基线开始，通过单用户对应用的访问获取性能取值的基线，然后设定可接受的性能目标（响应时间），用不同的并发用户数等重复进行测试。
Segue提供的这种性能测试方法非常适合性能调优和性能优化，通过不断重复的try-check过程，可以逐一找到可能导致性能瓶颈的地方并对其进行 优化。
EvaluateDevelop TestAssetsDevelop ExploratoryRe-BenchBaseLine &BenchmarkTuneSystemAnalyze ResultsTestsValidate Reg’sCriteriaMetComplete Project
图1.8 Segue Silk Performer提供的性能测试过程
但Segue提供的这个性能测试过程模型存在与LoadRunner的性能测试过程同样的问题， 就是过于依赖工具自身，另外，该过程模型缺乏对计划、设计的阶段的明确划分，也没有给出具体的活动和目标。
2.2 性能测试的方法
性能测试的方法很多，常见的比如说的“负载测试”和“压力测试”就是其中一些类型，此外还存在其他的一些类型的性能测试方法。
17 / 28


根据大范围的性能测试的概念的界定，性能测试可包括如下几种方法： 性能测试（Performance Testing）； 负载测试（Load Testing）； 压力测试（Stress Testing）； 配置测试（Configuration Testing）； 并发测试（Concurrency Testing）； 可靠性测试（Reliability Testing）； 失效恢复测试（Failover Testing）；
2.2.1 性能测试（Performance Testing）
性能测试（Performance Testing）方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。Performance Testing是一种最常见的测试方法，通俗地说，这种测试方法就是要在特定的运行条件下验证系统的能力状况。
这种方法的特点有：
（1） 这种方法的主要目的是验证系统是否有系统宣称具有的能力。
Performance Testing方法包括确定用户场景、给出需要关注的性能指标、测试执行和测试分析这几个步骤，这是一种完全确定了系统运行环境和测试行为的测试方法，其目的只能是依据事先的性能规划，验证系统有没有达到其宣称具有的能力。
（2） 这种方法需要事先了解被测试系统典型场景，并具有确定的性能目标。
Performance Testing方法需要首先了解被测西欧他能够的典型场景，所谓的典型场景，就是指具有代表性的用户业务操作，一个典型场景包括操作序列、并发用户数量条件。其次，这种方法需要有确定的性能目标，性能目标的描述基本上是这样的方式：“要求系统在100个并发用户的条件下进行某业务操作，响应时间不超过5秒”。
（3） 这种方法要求在已确定的环境下运行。
Performance Testing方法的运行环境必须是确定的。软件系统的性能表现与非常多的因素相关，无法根据系统在一个环境上的表现趋推断其在另一个不同环境中的表现，因此对这种验证性的测试，必须要求测试时的环境（硬件设备、 18 / 28


软件环境、网络条件、基础数据等）都已经确定。 2.2.2 负载测试（Load Testing）
负载测试（Load Testing）方法通过在被测系统上不断增加压力，直到性能指标，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。
这种测试放大可以找到系统的处理极限，为系统调优提供数据。在某些情况下，这种方法有时也被称为可量性测试（Scalability Testing）。该方法有这样一些特点：
（1） 这种性能测试方法的主要目的是找到系统处理能力的极限。
Load Testing方法通过“检测-加压-直到性能指标超过预期”的手段，其主要目的是找到系统处理能力的极限，这个极限一般会用“在给定条件下最多允许120个并发用户访问”或是“在给定条件下最多能够在1小时内处理2100笔业务”这样的描述来体现。而“预期的性能指标”一般会被定义为“响应时间不超过10秒”、“服务器平均CPU利用率低于65%”等指标。
（2）
这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测系统的与唯物压力量和典型场景，使得测试结果具有业务上的意义。
Load Testing方法由于涉及到“预定的性能指标”等需要进行比较的数据，也必须在给定的测试环境下进行。另外，Load Testing方法在“加压”的时候，必须选择典型场景，在增加压力时保证这种压力具有业务上的意义。
（3） 用。
Load Testing方法可以用来了解系统的性能容量（系统在保证一定响应时间的情况下能够允许多少并发用户的访问），或是用来配合性能调优，用这种方法比较调优前后的性能差异。
这种性能测试方法是一般用来了解系统的性能容量，或是配合性能调优来使2.2.3 压力测试（Stress Testing）
压力测试（Stress Testing）方法测试系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。
Stress Testing方法具有以下特点：
（1） 这种性能测试方法的主要目的是检查系统处于压力情况下时，应用的表现。
19 / 28


Stress Testing方法通过增加访问压力（例如，增加并发的用户数量等），使应用系统的资源使用保持在一定的水平，这种测试方法的主要目的是检验此时的应用表现，重点在于有无出错信息产生，系统对应用的响应时间等。
（2） 这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。 一般情况下，会把压力设定为“CPU使用率达到75%以上，内存使用率达到70%以上”这样的描述，在这种情况下测试系统响应时间、系统有无产生错误。除了CPU和内存使用率的设定外，“JVM的可用内存”、“数据库的连接数”、“数据库服务器CPU利用率”等都可以作为压力的依据。
（3） 这种性能测试方法一般用于测试系统的稳定性。
用压力测试的方法考察系统的稳定性是出于这样的考虑：“如果一个系统能够在压力环境下稳定运行一段时间，那么这个系统在通常的运行条件下应该可以达到令人满意的稳定程度”。在压力测试中，会考察系统在压力下是否会出现错误，测试中是否有内存等方面的问题。
2.2.4 配置测试（Configuration Testing）
配置测试（Configuration Testing）方法通过对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。
这种方法具有以下的特定：
（1） 这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
此配置测试方法不同于与功能测试并列的那个“配置测试”方法。对整个系统来说，配置测试是针对软件而言，其主要目的是验证软件能否在不同的软硬件环境中正常运行，其主要是功能上的验证。而这里提到的配置测试方法，是在性能测试领域内的配置测试方法，它的主要目的是了解各种因素对系统性能的影响程度，从而判断出对性能影响最大的因素。
（2） 这种性能测试方法一般在对系统性能状况有初步了解后进行。
Configuration Testing方法需要在确定的环境和操作步骤、确定的压力条件下进行。该方法在每次执行测试时更换、扩充硬件设备，调整网络环境，调整应用服务器和数据库服务器的参数设置，比较每次测试结果，从而确定各个因素对系统性能的影响，找出影响最大的因素。
20 / 28


（3） 这种性能测试方法一般用于性能调优和规划能力。
Configuration Testing方法主要用于“性能调优”领域，这种方法可以实现调优的持续进行。另外，在“规划能力”领域内，该方法也常被用来评估“该如何调整才能实现系统的扩展性”。
2.2.5并发测试（Concurrency Testing）
并发测试（Concurrency Testing）方法通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
该方法具有以下特点：
（1） 这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。 Concurrency Testing方法是通过并发的手段发现系统中存在问题的最常用方法。正如本章开头列举的问题，我们的应用在测试时一切正常，但一旦交付给用户，在用户量增大以后，就经常会出现各种莫名其妙的问题。解决这类问题的方法是进行仔细的并发模拟测试。
（2） 这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄露、线程锁和资源争用方面的问题。
Concurrency Testing在测试过程中主要关注系统的内存泄露、死锁等问题。表2-1列出了并发测试主要关注的问题。
表2-1 并发测试主要关注的问题
问题类别
问题描述
是否有内存泄露（C/C++）
内存问题
是否有太多的临时对象（java）
是否有太多的超过设计生命周期的对象（java） 是否有数据库死锁（Dead Lock）
数据库问题
是否经常出现长事务（Long Transaction）
线程/进程问题 其他问题
是否没有正常处理异常（例如超时等）导致系统死锁

（3） 这种性能测试方法可以在开发的各个阶段使用，需要相关的测试工具的配合和 21 / 28

是否出现线程/进程同步失败 是否出现资源争用导致的死锁

支持。
并发测试可以针对整个系统进行，也可以仅仅为了验证某个架构或是设计的合理性而进行，因此其可以在开发的各个阶段使用。一般来说，并发测试除了需要性能测试工具进行并发负载的产生外，还需要一些其他工具进行代码级别的检查和定位。Compuware公司的DevPartner工具、dj-technologie公司的JProfile工具、Quest公司的JProbe工具等可以在这方面发挥作用。
2.2.6可靠性测试（Reliability Testing）
这里说的“可靠性测试”并不等同于“获得软件的可靠性”，软件的可靠性是一个很大的命题，这里指的可靠性测试是通过给系统加载一定的业务压力（例如：资源在70%~90%的使用率），让应用系统运行一段时间、测试系统是否稳定运行。这里有三点需要注意：
（1） 在使用该测试前需要目的系统的资源使用率已经达到70%~90%。即在这样的苛刻环境下运行该应用系统。
（2） 应用系统运行起来后，加载业务压力使应用系统资源达到90%。比如：该J2EE系统中设置的JDBC数据库连接池定义为30，那么加载业务压力使连接达到27。
（3） 应用系统运行起来后结合业务情况来设定一个运行时间。比如：电力资产系统要求MTBF（平均无故障时间）达到10000小时、那么我们可以认定该系统的运行时间至少需要达到三年重新启动一次。超过这个数字我们就可以认为“不可靠”。一般情况下对于这个要求、我们让J2EE系统在资源使用率90%~100%状态连续稳定的运行3天左右没有错误就可以认定该MTBF指标已经达到。 该方法具有以下特点：
（1） 这种性能测试方法的主要目的是验证系统是否支持长期稳定的运行。
Reliability Testing方法的目的是验证系统是否能够支持长期稳定的运行，其原理在前面用非常粗糙的方式进行了一个解释。从直观上来说，在大的压力下进行一个较长时间的测试，如果系统在测试中不出现问题或者不好的征兆，基本上可以说明系统具备长期稳定运行的条件。
（2） 这种性能测试方法需要在压力下持续一段时间的运行。
既然是稳定性测试，肯定需要至少让系统在压力下运行一段时间。这段时间的具体数值需要根据系统的稳定性要求确定。对一般的非关键的大型应用来说，一般让系统处于可能的峰值压力下，进行2～3天的稳定性测试基本上就已经够了。
22 / 28


（3） 测试过程中需要关注系统的运行状况。
在运行过程中，一般需要关注系统的内存使用状况，系统的其他资源使用有无明显的变化，以及系统响应时间有无明显变化。如果测试过程中发现，随着时间的推移，响应时间又明显的变化，或是系统资源使用率有明显波动，都可能是系统不稳定的征兆，需要重点关注。
2.2.7失效恢复测试（Failover Testing）
该方法是针对有HACMP等冗余备份和Edge Server for LB等负载均衡的J2EE系统设计的。这种测试方法可以用来检验如果系统局部发生故障，用户是够能够继续使用系统；以及如果这种情况发生，用户将受到多大程度的影响。 该方法有以下特点：
（1） 这种性能测试方法的主要目的是验证在局部故障情况下，系统能否继续使用。 一般的关键业务都会采用双机热备或负载均衡方式来实现。这种业务系统一般要求即使有一台或几台服务器出现问题，应用系统仍然能够正常执行业务。Failover Testing方法可以在测试中模拟一台或几台设备故障，验证预期的恢复技术是否能够发挥作用。 （2） 这种性能测试方法还需要指出，当问题发生的时候“能支持多少用户访问”、“有多少功能不能使用” 的结论和“采取何种应急措施”的方案。
当一台或多台服务器出现问题后，系统一定会受到性甚至是功能上的部分损失。因此，必须在测试中明确得出“当问题发生时，系统还能支持多少用户的并发访问？是否要采取某些必要措施？”这种问题的明确答案。
（3） 一般来说，只有对系统持续运行指标有明确要求的系统才需要近些年过这种类型的测试。
不是所有的系统都需要进行这种类型的测试，尤其是并没有明确给出系统持续运行指标的系统。
三、性能测试分析方法
前一章着重介绍了目前常用的性能测试方法，本章主要简单介绍一下常用的各种性能测试分析方法。
1、内存分析方法
23 / 28


内存分析方法主要是用于判断系统有无遇到内存瓶颈，是否需要通过增加内存等手段提高系统性能表现。主要计数器包括Memory和Physical Disk类别的计数器。
内存分析的主要步骤和方法如下：
(1首先查看MemoryAvailable Mbytes指标
该值是用于描述系统可用内存的直接指标，在对系统进行操作系统级别的内存分析时，首先应通过该值建立一个初步的印象，了解性能系统测试过程中，系统是否仍然有足够的内存可用。
如果该指标的数据比较小，系统可能出现了内存方面的问题，此时需要进一步分析。
(2注意Pages/sec、Pages Read/sec和Page Faults/sec的值
操作系统经常会使用磁盘交换的方式来提高系统可用的内存量或是提高内存的使用效率。这三个指标直接反映了操作系统进行磁盘交换的频度。
如果Pages/sec的计数持续高于几百，很可能存在内存方面的问题，但其值很大不一定表示内存有问题，而可能是运行使用内存映射文件的程序所致。
Page Faults/sec说明了每秒发生页面失效的次数，页面失效次数越多，说明操作系统向内存中读取的次数越多。
此时还需要查看Pages Read/sec计数器，该计数器阀值为5，如果超过5，则可以判定存在内存方面的问题。
(3根据Physical Disk计数器的值分析性能瓶颈
对于Physical Disk计数器的分析包括Pages Read/sec和%Disk Time及Average Disk Queue Length的分析。
如果Pages Read/sec很低，同时%Disk Time和Average Disk Queue Length的值很高，则可能有磁盘瓶颈。
24 / 28


但是如果Average Disk Queue Length增加的同时Pages Read/sec并未降低，则是由于内存不足。
(备注：内存分析方法用到的计数器指标主要有：MemoryAvailable Mbytes、 MemoryPages/sec、Pages Read/sec和Page Faults/sec、Physical Disk%Disk Time、Average Disk Queue Length 2、处理器分析方法
处理器(CPU也可能是系统的瓶颈，对处理器进行性能分析的步骤如下：
(1首先查看System%Total Processor Time性能计数器的计数值
该值用于体现服务器整体的处理器利用率，对多处理器的系统而言，该数值体现的是所有CPU的平均利用率。
如果该值的数值持续超过90%，则说明整个系统面临这处理器方面的瓶颈，需要增加处理器来提高性能。
注意：由于操作系统本身的特性，在某些多CPU系统中，该数据本身并不大，但此时CPU之间的负载状况极不均衡，此时也应该视作系统产生了处理器方面的瓶颈。
(2其次查看每个CPU的Processor%Processor Time和Processor%User Time和Processor%Privileged Time。
Processor%User Time是指系统的非核心操作消耗的CPU时间，如果该值较大，可以考虑是否通过算法优化等方法降低该值。
如果服务器是数据库服务器，Processor%User Time值大的原因很可能是数据库的排序或函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。
(3研究系统处理器瓶颈
查看SystemProcessor Queue Length计数器的值，当该值大于CPU数量的总数+1时， 25 / 28


说明产生了处理器阻塞。在处理器的%Processor Time恒时候，一般都伴随着处理器阻塞，但产生阻塞时，Processor%Processor Time计数器的值并不一定很大，此时就需要查找处理器阻塞的原因。
%DPC Time是另一个需要关注的内容，该数值越低越好，在多系统处理器中，如果这个值大于50%并且Processor%Processor Time非常高，加入一个网卡可能会提高性能。
(备注：处理器分析方法所用到的主要计数器指标有：System%Total Processor Time、 Processor%Processor Time、%User Time、%Privileged Time、%DPC Time、
SystemProcessor Queue Length 3、磁盘I/O分析方法
通过对Physical Disk和Memory计数器值进行内存分析的方法，可以知道，磁盘I/O也是影响系统性能的一个关键因素。如果分析的计数器指标来自于数据库服务器、文件服务器或是流媒体服务器，磁盘I/O对系统来说更容易成为瓶颈。
以下是磁盘I/O的分析方法：
(1计算每磁盘的I/O数
每磁盘的I/O数可用来与磁盘的I/O能力进行对比，如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力，则说明确实存在磁盘的性能瓶颈。
下表给出了每磁盘I/O的计算公式：
(2与ProcessorPrivileged Time合并进行分析
如果在Physical Disk计数器中，只有%Disk Time比较大，其他值都比较适中，硬盘可能会是瓶颈。
26 / 28


若几个值都比较大，且数值持续超过80%，则可能是内存泄漏
(3根据Disk Transfer/sec进行分析
一般来说，定义该值小于15ms最为优异，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或硬盘的RAID方式了。
(备注：磁盘I/O分析方法用到的计数器有：ProcessorPrivileged Time、Physical Disk%Disk Time、Disk Transfer/sec 4、进程分析方法
(1查看进程的%Processor Time值
每个进程的%Processor Time反映进程所消耗的处理器时间。用不同进程所消耗的处理器时间进行对比，可以很容易的看出具体是哪个进程在性能测试过程中消耗了最多的处理器时间，从而可以据此针对应用进行优化。
(2查看每个进程产生的页面失效
可以用每个进程产生的页面失效(通过ProcessPage Failures/sec计数器获得和系统的页面失效(可通过MemoryPage Failures/sec计数器获得的比值，来判断哪个进程产生了最多的失效页面，这个进程要么是需要大量内存的进程，要么是非常活跃的进程，可以对其 进行中的分析。
(3了解进程的ProcessPrivate Bytes ProcessPrivate Bytes是指进程所分配的无法与其他进程共享的当前字节数量。该计数器主要用拉判断进程在性能测试过程中有无内存泄漏。例如：对于一个IIS之上的web应用，我们可以重点监控inetinfo进程的Private Bytes，如果在性能测试过程中，该进程的Private Bytes计数器值不断增加，或是性能测试停止后一段时间，该进程的Private Bytes仍然持续在高水平，则说明应用存在内存泄漏。
(备注：进程分析方法用到的计数器主要有：Process%Processor Time、Page 27 / 28


Failures/sec、Page Failures/sec、Private Bytes 5、网络分析方法
随着应用对数据传输量的增长，网络有时候也会成为系统性能的瓶颈，因此在对性能计数器进行分析的时候，也应该包括网络的部分内容。
网络分析是一件技术含量很高的工作，在一般的组织中都有专门的网络管理人员进行网络分析，对测试工程师来说，如果怀疑网络是系统的瓶颈，可以要求网络仍有来写真进行网络方面的检测。
Network InterfaceBytes Total/sec为发送和接收字节的速率(包括帧字符在内。可以通过该计数器的值判断网络连接速度是否是瓶颈，具体操作方法是用该计数器的值与目前的网络带宽进行比较。



28 / 28


本文来源：https://www.2haoxitong.net/k/doc/6279a7ec55270722182ef77d.html

《性能测试方法及分析方法.doc》
将本文的Word文档下载到电脑，方便收藏和打印
推荐度：
点击下载文档

文档为doc格式
相
关
案
例

相关推荐

推荐内容

住房按揭贷款信息表 高中作文-诗意地生活--高考优秀作文欣赏 系统并发测试方案 高考语文 满分作文赏析7《诗意地生活》素材 性能测试之测试用例(方案篇)_New 人教版道德与法治七年级上册教案：4.2 深深浅浅话友谊 文件汇编 部编版四年级上册语文1-8单元思维导图(知识点梳理) 民政局2021年清明节祭祀活动工作总结 重道笃行,通达致远——安徽省高速公路控股集团有限公司案例分析
网站内容来自网络，如有侵权请联系我们，立即删除！ Copyright © 范文写作网京ICP备16605803号