性能测试场景分析.docx

《性能测试场景分析.docx》由会员分享，可在线阅读，更多相关《性能测试场景分析.docx（29页珍藏版）》请在三一办公上搜索。

1、性能测试场景分析录制脚本 录制参数设置 脚本录制 回放和调试脚本 用这按钮进行编译，编译通过后，点击运行按钮即可运行脚本。只有在脚本运行正确后，才能进入Controller中来创建测试场景。 脚本录制的原则 n 充分考虑脚本的执行效率 n 录制重要的用户业务 n 选择你所需要的进行录制 修改脚本 参数化功能 步骤1： 步骤2： 步骤3： 参数类型有多种： l Date/Time：需要输入日期的地方，可以用Date/Time类型来替代。 l Group Name：使用虚拟用户组的名称来替代参数。 l Load Generator Name：使用虚拟用户所在的LoadGenerator机器名来替代

2、参数。 l Lteration Number：测试脚本当前循环的次数来生成参数。 l Random Number：随机数。 l Unique Number：唯一的数 l Vuser ID：使用虚拟用户的ID来替代参数，ID是由Controller来控制的。 l File：在属性中可以指定文件或数据库中提取数据。 l User Definde Function：从用户开发的dll文件中提取数据。 这里的重点是file类型： 在我们工作中最常用的是“Unique”和“Each iteration”的组合。比如我们设计一个场景，要求10个虚拟用户都需要进行10次迭代。那编号为1的用户取前10行数据，

3、编号为2的用户取1120行数据。以此类推，那完成整个场景就需要数据表里至少要有100条数据，否则在Controller运行过程中会返回一个错误。 深入集合点 使用集合点可以控制各个Vuser，以便在同一时刻执行任务。原理是，当某个Vuser到达该集合点时，Controller会将其保留，直到参与该集合点的Vuser都到达，满足了集合条件时，Controller将释放Vuser，这样就产生了密集的同一类用户操作或请求。Vuser从集合释放后，将执行脚本中的下一个任务。 需要注意的是： l 集合点一般会创建在用户事务的开始标志前。 l 集合点只能加在action部分，而不是init或end部分。

4、比如我们想在登录时创建一个集合点，我们可以这样安排： 巧用检查点 Loadrunner的检查点有三种：Web_find、Web_reg_find和Web_image_check。至于为什么要用检查点可以用个小例子做个测试，例如一个登陆脚本登陆的账号为123456，密码为123456，可以正确登陆，当把账号或密码改掉再执行，发现脚本并没有报错，也顺利执行下来了。原因是什么呢 ？Loadrunner以用户角色向服务器发送一个登陆请求，却不会判断请求的返回消息是什么，只要有返回，即使这是个拒绝登陆的返回，Loadrunner也认为登陆成功了。所以在登录或者其他有重要页面跳转的地方，很有必要做检查点。

5、 Web_find和Web_image_check两个函数如果在脚本里面增加，需要在设置中打开“图像和文本检查”功能，该功能默认是不打开的，如果手工在脚本里面添加检查点，系统会有提示： Action.c(43): Verification checks not enabled. web_find is skipped. See the Run-time settings/Preferences/Checks MsgId: MMSG-27197 Web_reg_find是注册类型函数，它本身并不执行，不能通过它的返回值来作为事务的判断条件就是把脚本中某些写死的资料，转变成是摘取自服务器所送的、动

6、态的、每次都不一样的资料。 关于检查点和关联的内容，可以参见我们的案例“01 checkproperties”。 另外，我们可以在中配置脚本运行时的设置。 运行逻辑：我们可以设置ACTION的迭代次数。 思考时间：我们一般忽略思考时间，以得到更大的压力。 其 他：我们可以选择错误的处理方式，还可以选择线程方式运行脚本以得到更大的压力，最后的选项一般默认就行了。 速度模拟：默认使用最大带宽，我们也可以模拟一些特殊的接入方式。 首 选 项：需要特别注意的是，如果脚本中使用了文本检查点或图片检查点的时候，此项一定要勾选中web_reg_find，则不要求勾选。） 其他的项我们一般都使用默认值即可。

7、，默认是没有勾选的。或，生成一定数量的虚拟用户。通过这些虚拟用户的并发执行以及及时间的运行，来模拟真实情况下服务器承受的压力。在场景运行的过程中，Controller可以提供对服务器资源、虚拟用户执行情况、事务响应时间等方面的监控，帮助测试人员实时的分析系统，并在运行完成后给出结果数据以便进行下一步的分析。 手动场景 在Controller中，新建场景时，我们选择上面的手动场景，也可以再选择使用百分比，不过不重要，我们可以在后面的手动场景是以用户定义虚拟用户数量来进行测试的。 这个菜单对其更改。 面向目标场景 在面向目标的测试场景中，可以定义希望达到的目标。比如最大虚拟用户数量或每秒事务数等。

8、Controller将根据定义的目标自动构建测试场景，并评估能否达到测试目标。 在这个下拉菜单中，我们可以定义虚拟用户数、每秒点击数、每秒事务数、每分钟页面数和事务响应时间5种类型的目标。 在这个图的下半部分，可以看到有两个标签页面：“场景设置”和“加载行为”。这两个标签页用来设置一些场景的参数，主要用在负载和压力测试的设定。 测试场景设计 配置测试脚本 在虚拟用户脚本加载后的界面上，选中需要配置的脚本后，点击右侧的可以查看和修改脚本。需要注意的是：修改后就好重新载入，不然会使用修改前的脚本。 虚拟用户数目和每组用户所在的负载生成器可以直接在此界面中输入。 配置Generator 使用Gene

9、rator可以使用多台安装了负载生成器的主机产生压力。 点击：= 点击：= 配置Schedule 点击： ，可以配置计划生成器 计划是场景配置的重要组成部分，主要用于配置用户的行为方式。这里有两种类型：按场景计划和按用户计划。 l 按场景计划 按场景计划有三个选项卡：加压、持续时间、减压。 加压中，第一个是同时加载所有用户，第二个是每隔一段时间加载一定的虚拟用户。 持续时间中，第一个是照脚本的设置进行，直到运行完成。这种方式主要用在检测特定功能的实现上，比如在并发时，程序会不会出现一些功能缺陷。第二个是按照指定的时间运行。如果选择此项，迭代次数的设置会被忽略，每个虚拟用户都不断的进行迭代，直到

10、指定时间为止。这种方式主要用在指定时间的性能测试。第三个是一直运行，直到人工干预为止。这种方式主要用来测试系统的极限。 减压中，才能操作减压选项卡），指定场景如何结束。这里对于加压，也是两种减压方式。 l 按用户计划 按用户计划有四个选项卡，后面三个和场景计划中是一样的。 注意在图左边的窗口中，有用户组的选择，可以对每个组进行独立的开始时间、加压减压和持续时间。特别是一组用户需要使用另一组用户的操作结果时，就必须使用按用户计划方式配置场景了。 我们重点讲解一下开始时间选项卡。 场景开始时运行。 场景开始后一段时间再开始，这里可以指定具体时间。 在某些特定的用户组运行结束后再开始。 需要注意的是

11、：也是一个选项。里面的第二和第三项一般是在运行时间很长，需要放到下班后执行时，我们可以选中它们。 配置集合点 我们之前讲过集合点，这里会具体配置集合点，以现实一定数量的并发，主要用来测试系统某个功能点的并发负载性能。 上面表示在03_checkproperties脚本中包含了一个集合点：maipiao。通过策略按钮我们可以配置它。 这里有三种方式： l 当Vu中全部指定百分比的虚拟用户到达集合点时释放。 l 当一定比例处于运行状态的虚拟用户到达集合点时释放。 l 当一定数量的虚拟用户到达集合点时释放。 最后一项是超时配置，如果在设定时间内都没有新虚拟用户到达集体点，Controller就会自动

12、释放到达集合点的用户。 配置IP Spoofer 现在一些服务器会对同一IP访问进行限制，这时我们可以通过“IP Spoofer”进行配置，以达到我们的测试目的。 我们只需要选择开始菜单中的“IP Wizard”，进入配置界面。 第二步需要选择网卡。 之后再在Controller中的菜单里，启用IP欺骗器就可以了。注意的是：必须在连接到负载生成器之前选择该选项。 再在工具菜单内选中专家模式，进入选项中的常规，就可以根据需要来配置了。 测试果设置 为了更好的管理我们越来越多的测试结果，可以在菜单中的设置结果目录，对其进行管理。 通用参数设置 在菜单的选项中，值得注意的是“超时”选项卡，其他选项一

13、般不用修改。在超时选项卡中，可以对负载生成器的连接、断开以及每个虚拟用户的初始化、运行、暂停和停止操作的超时时间进行设置，一旦超过设定，则会给出一条错误提示。 执行测试场景 启动测试场景 在场景的运行界面中有多个窗口，可以观查到场景组、场景状态、多个视图及它们的统计数据。 控制用户与用户组 在场景运行过程中，可以通过来对用户和用户组进行管理，包括添加、删除用户和用户组、控制虚拟用户运行状态等。界面如下： 查看场景与用户状态 通过场景状态区域的数据，我们可以监控场景与用户状态。在测试过程中就可以直接点击链接进行观看。 控制集合点 在场景的运行中，我们也可以像前面配置集合点一样的查看和控制集合点的

14、状态，即可以停止集合点和用户，也可以释放或重置集合点。 查看运行数据图 在Controller中，我们可以添加多种数据图进行查看。在右边的小窗口中，我们可以添加多种数据视图。 监控系统资源 在性能测试中，最重要的一项就是监控系统资源。需要监控这几个方面：操作系统、数据库、中间件服务器等，其中，操作系统的性能表现关系着整个应该系统的性能，属于基础的系统资源数据。需要注意的是：监控系统是一项消耗资源的操作，所以，测试过程一定要考虑具体监控什么，以免影响测试结果的准确性。 在监控系统之前，我们还需要做一些准备工作： l 打上监控主机上的“Network DDE”，“Remote Procedure

15、Call(RPC)”，“Remote Registry”，“Net Logon”等服务。 l 以系统管理员身份从Controller登录待监控主机。 l 在监控图中可以添加计算机，输入IP地址后，点击OK就行了。 l 在添架计算机的下面，我们再加入需要监控的计数器。 l 如果看到数据就是正常，否则检查服务和防火墙有无问题。 Windows监控的主要参数有：CPU占用率、可用内存容量、服务线程占用的CPU资源等。下面列出一些我们常用的计数器。 System System System System Processor Processor Memory % Total Processor Time

16、 File Data Operations/sec Processor Queue Length 系统上所有处理器非空闲线程的平均时间比。它反映了用于作业上的时间比率。 如果该值的数值持续超过90%，则说明整个系统面临这处理器方面的瓶颈，需要增加处理器来提高性能。 当前系统中磁盘文件读写的频繁程度。通过观察该计数器跟其他性能指标的变化趋势，通常能够判断磁盘文件操作是否是性能瓶颈。类似的计数器还有Network InterfaceBytes total/sec 线程单元中处理器队列的即时长度。此值为即时值，一般不超过2，否则表示处理器堵塞。 Total Interrupts/sec 所有处理器花

17、费在处理中断上的时间的总和。表示周边硬件设备的繁忙程度。 % Processor Time % User Time 提供了一个用100%减去CPU什么也不做的时间的衡量标准，系统可以更容易地衡量空闲线程运行的频率 Memory Memory Memory 处理线程用于执行使用用户模式的代码的时间的百分比。用户模式是为应用程序、环境分系统和整数分系统设计的有限处理模式。 用于描述系统可用内存的直接指标，在对系统进行操作系统级别的内存分析时，首先应通过该值建立一个初步的印Available Mbytes 象，了解性能系统测试过程中，系统是否仍然有足够的内 存可用。如果该指标的数据比较小，系统可能出

18、现了内存方面的问题，此时需要进一步分析。 每秒发生页面失效的次数，页面失效次数越多，说明操作Page Faults/sec 系统向内存中读取的次数越多。此时还需要查看Pages Read/sec计数器，该计数器阀值为5，如果超过5，则可 以判定存在内存方面的问题。 指在非分页池中的字节数，非分页池是指系统内存(操作Pool Nonpaged Byted 系统使用的物理内存)中可供对象(指那些在不处于使用 时不可以写入磁盘上 而且只要分派过就必须保留在物理内存中的对象)使用的一个区域。 Pages/sec 为解析内存对页面的引用而从硬盘读取的页数或定稿磁盘的页数。如果担心内存压力过大，这里需要考

19、虑。 性能测试结果分析 如何分析测试结果 在Controller中的执行的测试场景结束后，首先要判断采集的结果数据是否真实有效。多数场景都需要迭代执行，因此很多测试结果本身就不能反映真实问题，那我们一般按照以下几个步骤进行判断结果的有效性： 1. 测试环境是否正常： 如果在测试场景的过程中出现过异常，则结果往往不准确，无须进行分析。如CPU100%、网络断开。 2. 测试场景设置是否正常、合理： 测试场景的设置不合理会测试出现异常，这时需要对场景设置进行分析修正。如同时在一台PC上加载全部Vu，太多的Vu可能会造成客户端不能正常初始化，而造成很多Vu不能初始化而失败，这样的失败和我们要测试的服

20、务器根本没有关系。这时我们可以改为逐步加压。 3. 测试结果是否直接暴露出系统的一些问题： 性能测试的目的是分析出系统在压力下存在的问题，所以我们主要是对出现错误的结果进行分析。测试结果直接暴露的问题有很多，如： l 一些用户事务响应时间过长 l 系统支持最大的并发用户数过低 l 服务器CPU利用率过高 l 内存不足。 l 测试人员针对这些结果，用Analysis对其进行深入分析，以发现在一些潜在的性能问题。 性能分析基础知识 在性能测试中，我们都遵循一个普遍的原则：由外而内，由表及里，层层深入。 性能下降最直接的现象就是系统响应时间变长，所以我们都是以系统响应时间作为性能测试的切入点。而现在

21、的IT系统架构复杂，任何一个环节都可能出现瓶颈，要准确的判断出瓶颈在什么地方，是一个比较头痛的问题。我们分析问题的方法是：任何系统都是由网络和服务器构成的，所以我们先确定问题是出现在网络还是服务器上的。 借助LR的Analysis组件，可以很容易分析。如下图中，我们可以很容易的看出，在整个事务时间中，网络时间和服务器时间所占的多少，也可以很容易确定出问题主要现在在哪一个环节。 在实际的工作中，我们不能光发现问题，还要定位问题，并给出一个解决方案。即使有了正确的测试结果，也不一定能对问题进行正确的定位。比如说我们在工作中会经常遇到CPU占用率过高，我们可能还会发现磁盘IO过于频繁，我们一般会认为

22、是服务器内存不足。但也可能是因为程序内部的编写不严密，资源没有释放而造成的，也可能是因为程序内部有内存泄漏。解决工作实际问题不但要靠经验，也需要靠对系统的深入了解，所以说起码的编程能力还是很必要的。 Analysis基本功能 LR在Controller中运行场景，采集了Vu、操作系统、应用服务器等各种运行数据，当场景运行结束后，我们就可以用过LR专用的分析组件Analysis进行分析了。 当我们打开Analysis，通常是下面这样的一个界面： 在右边添加新图处，我们再进行打开新图的界面，这里还有很多的分析图 这里可以看到系统资源这些都是黑色，不是蓝色链接，说时这里没有采集到数据，我们需要在Co

23、ntroller中，场景运行之前开启相应的采集。 这里先简要介绍一下名类分析图的含义及用途。 l 虚拟用户图： 虚拟用户图里分为运行的虚拟用户图、虚拟用户概要和集合点3类，主要用来查看场景与会话的虚拟用户行为。 l 错误图： 主要有错误统计、每秒错误数量两类，用来查看服务器什么时间发生错误以及错误的统计信息，可以发现服务器的处理能力。 l 事务图： 描述和事务相关的分析图：事务综述图、事务平均响应时间图、每秒通过事务数图、每秒通过事务总数图、事务性能摘要图、事务响应时间与负载分析图、事务响应时间百分比图、事务响应时间分布图等。通过这些分析图，我们可以分析应用系统事务的执行情况。 l Web资源

24、图： 描述Web服务器的吞吐率图、点击率图、返回的HTTP状态代码图、每秒HTTP响应数图、每秒重试次数图、重试概述图、服务器连接数概要图、服务器每秒建立的连接数量图。借助Web资源图，我们可以深入分析服务器性能。 l 网页细节图： 网页细分需要在Controller中启动。在网页细分图中主要有：页面分解总图、页面组件细分图、页面组件细分图、页面下载时间细分图、页面下载时间细分图、第一次缓冲时间细分图、第一次缓冲时间细分图、已下载组件大小图。借助网页细分图，我们可以分析页面元素是否影响事务响应时间。 l 系统资源图： 系统资源图描述在场景运行期间，由联机监控获得的系统资源使用情况。要获得系统资

25、源情况，必须在Controller里预先指定相关的计数器。 如何看Analysis图 我们使用Analysis分析，一般按以下几步来处理： 第一页：首先从摘要开始。 摘要主要是判定事务的响应时间与执行情况是否合理。如果发现问题，则需要做进一步的分析。这里一般需要重视的是事务执行失败和响应时间过长等。 下面是查看分析摘要时的一些原则： 用户是否全部运行，最大运行并发用户数是否与场景设计的最大运行并发数一致。如果没有，则需要打开与虚拟用户相关的分析图，进一步分析虚拟用户不能正常运行的详细原因； 事务平均响应时间、90%事务最大响应时间用户是否能接受。如果事务响应时间过长，则要打开与事务相关的各类分

26、析图，进行深入分析。 查看事务是否全部通过。如果有失败的情况，则需要深入分析原因。很多时候，执行失败就说明系统有瓶颈。 如果一切正常，则本次测试没有必要进行深入分析，重新加大压力进行测试。 如果事务失败过多，则应该降低压力进行测试，使结果容易分析。 第二：查看负载发生器和服务器的系统资源情况。 查看分析概要后，接下来要查看负载发生器和待测服务器的系统资源使用情况：查看CPU的利用率和内存使用情况，尤其要注意查看是否存在内存泄漏问题。这样做是由于很多时候系统出现瓶颈的最直接表现就是CPU占用率过高和内存不足。 这个测试应保存证负载发生器在整个测试过程中CPU、内存、带宽没有出现瓶颈，否则测试结果

27、无效，如果硬件上都有瓶颈则不能表现出程序中的问题来。 第三：查看虚拟用户与事务的详细执行情况。 在前两步确定了测试场景的执行情况基本正常后，接下要查看虚拟用户与事务执行情况。 对于虚拟用户，主要看看在整个测试过程中是否运行正常，如果有较多用户不能正常运行，则需要重新设计场影或调整init和end内容重新测试。 对于事务，主要看整个过程的事务响应时间是否逐渐变长以及是否存在不能正常执行的事务。 下面是虚拟用户与事务分析的常用准则： l 虚拟用户如有失败，则要查明原因； l 在整个测试过程中，所有的虚拟用户是否一直稳定运行并成功执行全部事务。如果仅有一个用户或部分用户能够正常运行，则说明测试脚本可

28、能存在问题。 l 对于失败的事务首先要分析其失败原因，接着要查看事务的失败是否导致用户失败； l 判断用户是否可以接受事务平均响应时间值以及90%用户的最大响应时间值； l 查看整个测试过程的事务平均响应时间是否逐渐变长，正常情况下，事务平均响应时间的变化应该是一条接近平行于X轴的直线； l 事务响应时间是否在整个测试过程中随着用户的增加而线性变短。正常情况应该是当一定范围内的用户并发时，事务响应时间应不会有太大变化； l 服务器每秒通过的事务总数、某一事务每秒通过数是否稳定，如果整个测试过程基本不变，则要分析是服务器达到了处理上限还是Generator产生的压力达到了上限； l 按照迭代次数

29、来运行的场景，要分析通过的事务总数是否与设定一致，如果不一致，则可能脚本有问题，也可能是程序存在功能错误，应调整后再测。 Analysis对虚拟用户和事务提供了非常强大的跟踪功能，可以跟踪每一个用户及其相关事务的执行情况。这些内容可以在菜单“报告”中的“crystal 报告”里找到。 第一步：查看错误发生情况。 整个测试过程的错误发生情况是分析的重点。下面是错误发生情况的常用准则： l 查看错误发生曲线在整个测试过程中是否有规律变化，如果有，则意味程序在并发处理方面存在一定的缺陷。如果没有规律，则可以将步调调慢一点，达到更好的测试效果，或可能是脚本有问题。 l 查看错误分类统计，作为优化系统的

30、参考。比如“超时错误”达到90%以上，可能需要硬件上提高配置了；再比如出现较多的“内部服务器错误”，则可能是程序方面存在问题。 第二步：查看Web资源与细分网页。 现在的系统多是Web广域网系统，所以需要很多的重视Web性能的测试。查看Web图时，往往需要结合前而对虚拟用户以及事务响应时间的分析结果，重点分析服务器的稳定性。对于网页细分功能则应遵循如下原则： l 分析从用户发出请求到收到第一个缓冲为止，哪些环节比较耗时； l 找出页面中哪些组成部分对用户响应时间影响较大； l 找到页面性能问题后，提出调优方案； l 测试调优后的性能能否达到要求。 在性能测试中，我们除了要使用Analysis分

31、析外，还要借助其他分析工具，比如：Oracle、WebLogic等软件都有自己的监控和分析工具，以达到更好的测试效果。 细述分析图 虚拟用户图 虚拟用户图显示Vuser状态、完成脚本的Vuser数量以及集合点的统计信息。虚拟用户图主要有三类：正在运行的虚拟用户图、虚拟用户概要图、集合点图。 正在运行的虚拟用户图 正在运行的虚拟用户图一般会和一些事务响应合并起来一起分析。下图我们把用户和windows资源及事务图一并结合起来，可以看到用户对事务和资源的影响： 虚拟用户概要图 查看各个虚拟用户的成功比例。 集合点图 主要查看集合点的执行情况： 事务图 Analysis和事务相关的分析图有：事务摘要

32、图、事务平均响应时间图、每秒通过事务总数图、事务性能摘要图、事务响应时间与负载分析图、事务响应时间图、事务响应时间分布图。通过这些图可以很容易分析整个测试过程的事务执行情况。 事务摘要图 这里有两组不同压力测试的事务图，可以很明确的看到压力大的时候，系统出错的情况更严重，特别是“maipiao”这一事务进而影响到action事务。因为我们在maipiao事务前设置了一个集合点，说明了系统在并发上存在一定的性能瓶颈。 事务平均响应时间图 事务平均响应时间图是在测试场景运行过程中的每一秒内，执行各个事务所用的平均时间，通过它可以分析测试场景运行过程应用系统的性能走向。 一般来说一个性能稳定的系统应

33、该是一条基本平等于X轴的线条，这里紫色的起伏较大的线条是包含集合点“maipiao”的action事务。如果说系统存在内存泄漏的问题，那就是一起向右上逐渐倾斜的线条。 每秒通过事务数图 描述在场景运行的每一秒中，每个事务通过、失败以及停止的数量，是考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的实际事务负载，通过分析单位时间内通过的事务数，可以看出系统的性能变化赵势。 当压力增大时，每秒通过事务数图以及稍后介绍的点击率图的曲线如果变化缓慢或比较平坦，那服务器很可能存在瓶颈。所以，分析每秒通过事务数图主要是看曲线的走向。 每秒通过事务总数图 每秒通过事务总数图是场景在运行时每一秒通

34、过的事务总数、失败的事务总数以及停止的事务总数。在系统性能稳定的情况下，应该是接近一条直线，而不是逐渐倾斜。 事务性能摘要图 事务性能摘要图显示了场景中所有事务的最大、最小和平均执行时间，可以直接判断响应时间是否符合用户的要求。在此图中，我们可以单击右键，选择“Show Transaction Breakdown Tree”显示所选事务细分树图。如果双击图中较为关注的子事务，将会显示对应事务的最大、最小和平均执行时间。 事务响应时间与负载分析图 此图是正在运行的虚拟用户图和事务平均响应时间的组合。通过它可以看出任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据。 事务

35、响应时间）图 此图是根据测试结果进行分析而得到的综合分析图。假设期望“Action”事务在50秒内完成，在下图看来，有90%的用户达到这一目标。如果是期望“maipiao”事务在10秒内完成，目前看到，100%的用户都达到了这一目标。 事务响应时间分布图 对此图进行分析，主要看其是否有强烈的延续。如果有，则说明存在很多响应时间过长的事务。在下图中，Action事务有很强的延续性，说明有很多事务响应时间过多了，在这里，可能是因为有集合点。因为Action中“maipiao”事务的响应时间很短，而Action事务中只有一个maipiao的事务，所以可能是有集合点的原因，也可能是脚本的问题，如果排除

36、这两个问题，还可能是并发的问题了。 事务图总结 分析用户事务的执行情况是性能分析的第一步。通过深入分析用户事务的响应时间是否合理，可以判断系统性能是否合符用户的要求。如果通过用户事务分析发现有问题，那么要Web资源进行分析。 Web资源图 Analysis中的Web资源图主要通过点击率、吞吐率、每秒HTTP响应数、每秒连接数等测试来分析Web服务器的性能。通过多次不同压力下各种Web资源的结果数据对比，可以知道系统的性能走向和性能瓶颈。 点击率图 点击率图是指在场景运行中虚拟用户每秒向Web服务器提交的HTTP请求数，既可以依据点击次数来评估虚拟用户产生的负载量，也可将其与事务平均响应时间图进

37、行比较，可以看到点击次数对事务性能的影响。 从这里可以看到，在3分44秒的时候，出现了第一个压力高峰，每秒23次的点击，这里出现了一个响应的瓶颈。图表右半部分反应来看，系统还是比较稳定的。出现较大的规律的波动的原因是什么呢？ 吞吐率图 吞吐率图是指在场景运行过程中服务器每秒的吞吐量。它描述的是每秒虚拟用户从服务器获得的数据量。根据吞吐量可以评估虚拟用户产生的负载量。 吞吐量和点击率的形状是基本相似的，如果吞吐量和点击率图都出现与事务无关的左高右低，则说明服务器性能有下降的趋势。此图中的左高右低的原因和前面点击率的情况是一样的，所以此处的左高右低并不能说明服务器性能有所下降。 每秒HTTP响应次

38、数图 此图是指场景运行过程中每秒从Web服务器返回的不同HTTP状态代码的数量，其按照状态代码分组。 这里需要说明的是，LR只把返回状态代码为200的认为是正常，其他都认为是错误。下面列出常见的状态代码的含义。 1xx - 信息提示 这些状态代码表示临时的响应。客户端在收到常规响应之前，应准备接收一个或多个 1xx 响应。 100 - 继续。 101 - 切换协议。 2xx - 成功 这类状态代码表明服务器成功地接受了客户端请求。 200 - 确定。客户端请求已成功。 201 - 已创建。 202 - 已接受。 203 - 非权威性信息。 204 - 无内容。 205 - 重置内容。 206

39、- 部分内容。 3xx - 重定向 客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求。 302 - 对象已移动。 304 - 未修改。 307 - 临时重定向。 4xx - 客户端错误 发生错误，客户端似乎有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份验证信息。 400 - 错误的请求。 401 - 访问被拒绝。IIS 定义了许多不同的 401 错误，它们指明更为具体的错误原。这些具体的错误代码在浏览器中显示，但不在 IIS 日志中显示： 401.1 - 登录失败。 401.2 - 服务器配置导致登录失败。 401

40、.3 - 由于 ACL 对资源的限制而未获得授权。 401.4 - 筛选器授权失败。 401.5 - ISAPI/CGI 应用程序授权失败。 401.7 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。 403 - 禁止访问：IIS 定义了许多不同的 403 错误，它们指明更为具体的错误原因： 403.1 - 执行访问被禁止。 403.2 - 读访问被禁止。 403.3 - 写访问被禁止。 403.4 - 要求 SSL。 403.5 - 要求 SSL 128。 403.6 - IP 地址被拒绝。 403.7 - 要求客户端证书。 403.8 - 站点访

41、问被拒绝。 403.9 - 用户数过多。 403.10 - 配置无效。 403.11 - 密码更改。 403.12 - 拒绝访问映射表。 403.13 - 客户端证书被吊销。 403.14 - 拒绝目录列表。 403.15 - 超出客户端访问许可。 403.16 - 客户端证书不受信任或无效。 403.17 - 客户端证书已过期或尚未生效。 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码 IIS 6.0 所专用。 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。 403.20 - Passport 登录失败。这

42、个错误代码为 IIS 6.0 所专用。 404 - 未找到。 404.0 - 没有找到文件或目录。 404.1 - 无法在所请求的端口上访问 Web 站点。 404.2 - Web 服务扩展锁定策略阻止本请求。 404.3 - MIME 映射策略阻止本请求。 405 - 用来访问本页面的 HTTP 谓词不被允许 406 - 客户端浏览器不接受所请求页面的 MIME 类型。 407 - 要求进行代理身份验证。 412 - 前提条件失败。 413 请求实体太大。 414 - 请求 URI 太长。 415 不支持的媒体类型。 416 所请求的范围无法满足。 417 执行失败。 423 锁定的错误。

43、5xx - 服务器错误 服务器由于遇到错误而不能完成该请求。 500 - 内部服务器错误。 500.12 - 应用程序正忙于在 Web 服务器上重新启动。 500.13 - Web 服务器太忙。 500.15 - 不允许直接请求 Global.asa。 500.16 UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。 500.18 URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。 500.100 - 内部 ASP 错误。 501 - 页眉值指定了未实现的配置。 502 - Web 服务器用作网关或代理服务器时收到了无效响应。 502.1 - CGI 应用程序超时

44、。 502.2 - CGI 应用程序出错。 503 - 服务不可用。这个错误代码为 IIS 6.0 所专用。 504 - 网关超时。 505 - HTTP 版本不受支持。 每秒连接数图 此图是描述场景在运行中每秒新建的TCP/IP连接数。新连接数应该是每秒点击次数的一小部分，因为就系统资源来说，新的TCP/IP连接非常耗费资源。 下面上看，服务的性能有不太明显的性能下降，因为连接断开和新连接的数量都在逐渐下降。如果说连接断开和新连接数都下降为0了，说明系统崩溃，有严重性能问题，很不稳定，不能投产。 网页细分图 网页细分图主要用来评估页面内容是否影响事务响应时间，通过它可以深入分析网站上哪些下载

45、很慢的图像或中断的链接等有问题的元素，可以方便的对问题进行比较精确的定位。网页细分图多用于分析在事务性能摘要图和事务平均响应时间图中检测到的问题。可以将网页细分图中的数据和事务性能摘要图和事务平均响应时间图中的数据关联起来，综合分析性能出现的是网络问题还是服务器问题。 网页细分图主要有：页面分解总图、页面组件细分图、页面组件分解图、页面下载时间细分图、页面下载时间细分图、第一次缓冲时间细分图、第一次缓冲时间细分图、已下载组件大小图。 页面分解总图 此图描述某一具体事务在测试过程中的响应情况，进而分析相关的事务是否运行正常。 上图针对于Action和maipiao事务进行查看，Action响应时

46、间有变长的趋势，maipiao事务有细微的起伏，总的来说是比较稳定的。 页面分解总图有四种方式细分： 1. 下载时间细分： 在下载时间细分图中，不但要分别显示网页中不同元素的下载时间，同时还要按照下载过程将时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占的比例。 通过下载时间细分图可以很容易看出各个元素所用的时间长短，以及下载过程对时间进行的分解，为调整程序提供依据。 2. 组件细分： 组件细分图是指选定网页的页面组件随时间变化细分图。在此图中，可以选择不同的元素以查看测试过程中其下载时间的变化曲线，发现不稳定的元素。需要在客户端下载控件较多的页面要特别重

47、视此图。 3. 下载时间细分 下载时间细分图显示选定网页的页面元素下载时间细分时间变化的情况，它非常清晰的显示了页面中各个元素在压力负载下的下戴情况。 对比图： 上面的图中连接的响应时间变长了不少，接收时间也变长了，说明系统在压力加大的情况下有延迟，如果延迟的时间是客户可以接受的范围内，系统也是可以接受的。 4. 第一次缓冲时间细分 显示选定网页的第一次缓冲时间细分情况。分析第一次缓冲时间细分图，首先要理解什么是第一次缓冲时间。它是指客户端与服务器建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端后，到浏览器接收到第一个缓冲所用的时间。 第一次缓冲时间细分图主要显示页面不同