|
|
知识路径： > 测试技术的分类 > 应用负载压力测试 > 负载压力测试解决方案 >
|
|
相关知识点：10个
|
|
|
|
|
系统的并发性能是负载压力性能的最主要的组成部分，首先我们来讨论什么是“并发”。对一个系统来讲，某些业务操作对特定角色用户来讲存在很大的同时操作的可能性。例如，网上购物系统的订单提交、订票系统的票源查询、人力资源系统月末及年末报表上传等，客户端大量的并发操作提高了网络的吞吐量，加剧了服务器资源互斥访问冲突，加大了数据库死锁的可能。这样的负载压力轻则会导致系统性能低下，重则会对系统造成破坏，给用户带来经济损失。因此并发性能的测试对于保证系统的性能是非常关键的。
|
|
|
|
那么，在实际操作中，我们采取什么样的方案来实施这一类操作呢？首先并发负载压力的实施是在客户端，负载压力的传输介质是网络，最终压力会到达后台各类服务器，包括Web服务器、应用服务器、数据库服务器以及系统必须的服务器，例如认证服务器、检索服务器等。所以，在并发性能测试过程中，关注点包括客户端的性能、应用在网络上的性能以及应用在服务器上的性能。为什么这些内容都是必须的呢？大家知道，测试是要定位问题，目的是为了解决问题，这些关注点正是定位问题的必要条件。下面将详细论述这些重点内容。
|
|
|
|
|
|
在客户端模拟大量并发用户执行不同业务操作，达到实施负载压力的目的。
|
|
|
|
采用负载压力测试工具来模拟大量并发用户，模拟机制如下图所示，主要组成部分包括主控台、代理机以及被测服务器，各部分采用网络连接。主控台负责管理各个代理以及收集各代理测试数据，代理负责模拟虚拟用户加压。在每次并发性能测试中，只有一台主控台，但可以有多个代理。
|
|
|
|
|
|
|
|
如何模拟负载压力呢？总的原则是最大限度地模拟真实负载压力。要做到这一点，既是对测试工具的考验，又是对测试工程师经验与智慧的考验。
|
|
|
|
测试工具怎样模拟真实的负载压力呢？以LoadRunner负载压力测试工具为例，看看工具是如何实现的。
|
|
|
|
要模拟真实的负载压力做测试，必须创建方案，方案是用以模拟现实生活中用户的方式。方案包含有关如何模拟实际用户的信息：虚拟用户（Vuser）组、Vuser将运行的测试脚本，以及用于运行脚本的负载生成器计算机。
|
|
|
|
如果选择创建常规手动方案，则会将选择的每个脚本分配给Vuser组。然后，可以为每个Vuser组分配多个Vuser。可以指示某个组中的所有Vuser在同一台负载生成器计算机上运行相同的脚本，也可以为组中的各个Vuser分配不同的脚本和负载生成器。使用百分比模式创建手动方案，可以定义方案中要使用的Vuser总数，并为每个脚本分配负载生成器和占总数一定百分比的Vuser。
|
|
|
|
可以设计面向目标的方案，在面向目标的方案中，可以定义所希望实现的测试目标，LoadRunner将根据定义的目标自动创建一个方案。在一个面向目标的方案中，可以定义五种类型的目标：虚拟用户数、每秒点击次数（仅Web Vuser）、每秒事务数、每分钟页面数（仅Web Vuser）或事务响应时间。要定义每秒事务数或事务响应时间目标类型，脚本中必须包含事务。对于每种目标类型，可以定义脚本中希望测试的事务。下面分别来分析五种类型的目标。
|
|
|
|
. 虚拟用户目标类型：测试应用程序可以同时运行多少个Vuser。
|
|
|
|
. 每秒点击次数、每分钟页面数或每秒事务数：测试服务器的稳定性。需要指定LoadRunner运行的Vuser范围（最大值、最小值），以及每秒事务数目标类型的“事务名称”。Controller（测试工具的主控台）将尽量使用最少数量的Vuser来达到定义的目标。如果使用最小Vuser数不能达到该目标，则Controller将逐渐增加Vuser数，直到达到所定义的最大数。如果使用指定的最大Vuser数仍不能达到指定的目标，Controller将增加Vuser数，并再次执行方案。
|
|
|
|
. 事务响应时间目标类型：测试在期望的事务响应时间内可以同时运行多少个Vuser，在脚本中指定想要测试的事务的名称以及LoadRunner要运行的Vuser数量范围（最大值、最小值）。指定的“事务响应时间”应该是一个预定义的阈值。例如，如果希望用户在5秒钟之内登录到某个电子商务站点，请将可接受的最长事务响应时间指定为5秒。将最大和最小Vuser数设置为希望能够同时提供服务的最大和最小用户数。如果方案没有达到定义的最大事务响应时间，则服务器能够在合理的时间间隔内，对想要同时提供服务的指定数量的用户作出响应。如果在仅执行部分Vuser后就达到定义的响应时间，或如果接收到消息，提示如果Controller使用定义的最大Vuser数，响应时间将超出指定值，那么，应该考虑修补应用程序和/或升级服务器的软硬件。
|
|
|
|
下面来谈谈方案计划。方案的主要内容是确定如何开展测试，以准确描绘用户行为（操作类型和这些操作的计时等，由Vuser脚本表示）。可以在一段延迟之后开始执行方案。可以指定LoadRunner自发出Run命令以来等待的分钟数，也可以指定让方案开始的特定时间。使用计划生成器，可以对手动方案进行计时设置，从而限制方案的执行持续时间，或Vuser组在方案中的持续时间。通过指定方案或Vuser组应处于“正在运行”状态的分钟数，可以限制执行持续时间。方案或组到达其时间限制时就结束。对于手动方案，还可以规定在某一时间段内LoadRunner启动和停止的Vuser的数量。在指定的时间量内，可以指定LoadRunner应同时启动/停止，Vuser组中所有的Vuser，还是仅启动/停止一定数量的Vuser。需要注意的是，Vuser脚本中的集合点将干扰已计划好的方案。如果脚本包含集合点，则方案将不会按计划运行。
|
|
|
|
在方案运行期间，可以通过使用集合点指示多个Vuser同时执行任务。集合点可以在服务器上创建密集的用户负载，并使LoadRunner能够测量服务器在负载状态下的性能。假设有10个Vuser同时检查账户信息时，需要估量某个基于Web的银行系统如何执行操作。为了模拟服务器上要求的用户负载，可以指示所有的Vuser完全在同一时刻检查账户信息。通过创建集合点，可以确保多个Vuser同步操作。当Vuser到达某个集合点时，它就会被Controller滞留在该处。当达到要求的Vuser数或者经过一段指定的时间后，Controller就会从集合中释放Vuser。
|
|
|
|
通过使用Controller，可以根据如下选择来影响服务器的负载级别：
|
|
|
|
|
|
|
|
例如，要测试银行服务器，可以创建一个包含两个集合点的方案。第一个集合可以确保1000个Vuser能同时存入现金。第二个集合可以确保另外1000个Vuser能同时提取现金。如果需要在只有500个Vuser存入现金的情况下度量服务器的性能，可以停用（禁用）“提取”集合，并指示仅让500个Vuser参加“存入”集合。下面的过程概述了如何控制服务器上的负载峰值。
|
|
|
|
|
|
|
|
. 向方案中添加Vuser组时，LoadRunner扫描与该组相关的脚本，在其中搜索集合点的名称，并将这些名称添加到“集合信息”对话框中的列表里。如果创建另外一个运行相同脚本的Vuser组，Controller会将该新的Vuser添加到集合中，并更新列表。
|
|
|
|
|
|
. 通过选择将加入到方案中的集合点，以及加入每个集合的Vuser数，可以确定负载的精确级别。
|
|
|
|
|
|
|
|
|
|
在运行方案之前，可以同时配置方案的负载生成器和Vuser行为。虽然默认设置与大多数环境对应，但是LoadRunner允许修改这些设置，以便自定义方案行为。这些设置适用于所有未来的方案运行，并且通常只需设置一次。如果全局方案设置与单个负载生成器的设置不同，则负载生成器设置将替代全局方案。
|
|
|
|
这里讨论的设置与Vuser运行时的设置无关。这些适用于单个Vuser或脚本的设置，包含有关日志记录、思考时间、网络、迭代数和浏览器的信息。LoadRunner导出模式允许配置LoadRunner代理程序和其他LoadRunner组件的其他设置，称为“专家模式”。
|
|
|
|
我们使用大量的篇幅论述了测试工具，其实在测试过程中，占主导地位的仍然是测试工程师，测试工程师对测试工具掌握的熟练程度，负载压力测试积累的经验，对新技术的敏感程度，和开发人员及用户的充分交流，学无止境的工作态度都是非常重要的。
|
|
|
|
测试工程师只有程序设计和开发工具的知识是不够的，必须要懂得系统运转的机理。要具备应用平台、软件架构、数据库系统以及网络环境等方面的知识，这样才能做到尽量分析错误和定位错误。
|
|
|
|
例如，当对关键功能点录制脚本时，不但要掌握功能点完成的任务，还要熟悉功能的业务运行模式，这就需要测试工程师有业务操作背景。
|
|
|
|
客户端并发性能测试要得到哪些指标的值呢，以及怎样分析结果值，我们在后面章节会有详细举例论述。
|
|
|
|
|
|
这部分主要包括两部分内容，一是应用网络故障分析；二是网络应用性能监控。
|
|
|
|
应用网络故障分析的测试目标是显示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。通过测试，我们可以做到下面几点。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
③模拟最终用户在不同网络配置环境下的响应时间，决定应用投产的网络环境。
|
|
|
|
网络故障分析工具的工作机理，可以总结为“多个捕捉点，一个分析”。捕捉点即“Agent”，利用主控台“Agent Manager”进行分析，Agent被动监听数据包来实现实时数据采集，Agent Manager完成对所跟踪到的数据的分析，可以自由地将捕捉代理放在不同的平台，例如，Windows或UNIX。如下图所示的主控台为Management Console，捕捉点为代理探针Probe。
|
|
|
|
|
|
|
|
如下图所示是一个典型的Web架构应用部署图，我们可以在应用逻辑路径上进行多点数据采集，并且在任何两个节点间进行数据整合，测量分段的响应时间，分析应用故障。
|
|
|
|
|
|
|
|
|
|
. 监控不同探针之间的连接状态，传输的字节数以及通信往返行程次数，如下图所示，206.40.55.195为浏览器，www.optinal.com为Web服务器，其上各有一个
|
|
|
|
探针，将网络分为两段，分别是Primary和Secondary。
|
|
|
|
|
|
|
|
. 会话性能概要，监控哪段网络延迟大，带宽对网络双向性能的影响，节点用于处理和用于传输的时间等，如下图所示。
|
|
|
|
|
|
|
|
. 服务器与客户端之间帧传输情况统计，可以监控到与应用相关的帧的分布，对每一个帧可以与相关的数据包关联，并且可以对帧解码，如下图所示。
|
|
|
|
|
|
|
|
. 服务器与客户端之间传送包信息统计，监控包的详细信息，并且可以将包与帧及线程相关联，如下图所示。
|
|
|
|
|
|
|
|
. 线程信息统计，监控线程的内容和生存周期，以及线程与数据包的关系，如下图所示。
|
|
|
|
|
|
|
|
. 负载的高峰时刻，监控到负载的平均值以及高峰值，并且高峰时刻可以与相关的线程、数据包、帧相关联，如下图所示。
|
|
|
|
|
|
|
|
|
|
①应用级错误：HTTP, FTP, DNS, FTP, No response seen, repeated DNS request, …
|
|
|
|
②TCP错误：retransmissions, missing data, frame out of sequence, connection errors, resets, …
|
|
|
|
③IP错误：missing fragment, missing fragment data, …
|
|
|
|
④其他错误：ICMP, Improper frame，…
|
|
|
|
网络应用性能监控的测试目标，是在系统试运行之后，我们需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争。
|
|
|
|
利用工具进行网络应用性能监控，监控探针可以部署在整个应用范围内，如下图所示。监控工具主要包括以下部分：
|
|
|
|
|
|
|
|
①探针。采集与存储数据，并根据应用对数据进行分类。设置的原则是根据网络组成和监控要求。
|
|
|
|
②探针管理器。管理配置探针，设定数据采集与上传时间，合并收集的数据。
|
|
|
|
|
|
|
|
用户关心的需要进行网络监控的问题主要有以下几个方面。
|
|
|
|
|
|
. 定位问题的根源是在客户端、服务器、应用程序还是网络；
|
|
|
|
|
|
|
|
|
|
. 应用监视：1500多种应用及15种定义模式、网络的硬件设备、网络应用的流量和流量的拓扑结构，如下图所示为测试工具中提供的应用监视。
|
|
|
|
|
|
|
|
. 关键特性：客户和服务器通信量、应用响应时间和资源应用的业务水平等，如下图所示为工作站信息。
|
|
|
|
|
|
|
|
. 按会话统计传输负载：测试应用和会话级响应时间，以及自动为通过网络中每一个联网设备的每一个应用程序生成负载图。
|
|
|
|
. 应用、会话级、事务响应时间；如下图所示为应用的响应时间等相关信息。
|
|
|
|
|
|
|
|
. 测试延迟是在何处被引入网络的，瓶颈在哪里。如下图所示为日应用流量相关信息，很容易定位高峰瓶颈时刻。
|
|
|
|
|
|
|
|
. 趋势分析。应用在网络上性能测试要得到哪些指标的值呢，以及怎样分析结果值，我们在后面章节会有详细的举例论述。
|
|
|
|
|
|
这里我们谈到的“测试”的概念就是对服务器执行监控。监控的内容主要包括操作系统、数据库以及中间件等。目前监控的手段可以采用工具自动监控，也可以使用操作系统、数据库、中间件本身提供的监控工具。利用工具监控有下列优点。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
. 故障诊断和恢复：自动报警、故障恢复程序、故障恢复信息；
|
|
|
|
|
|
操作系统、数据库、中间件本身提供的监控工具有时采用命令行的方式，有时具备友好的图形界面，例如，Saloris监控服务器资源占用可以使用vmstat或者iostat命令，Web应用中间件Websphere的监控可以采用系统本身提供的Web页面的监控工具，当然也有一些用于特定系统的监控工具，例如用于AIX操作系统的监控工具nmon32。
|
|
|
|
操作系统的监控涉及后台重要服务器操作系统监控，如果系统采用负载均衡机制，那么还有必要验证负载均衡是否能处理大的客户端压力，并且正确实现负载均衡。操作系统有很多种类型，监控的指标也不尽相同，但对于主流的操作系统，我们最关注的指标包括三个，即CPU、内存以及硬盘，这些指标怎样分析以及对其他关联指标的影响如何，在后面章节我们会以实例的形式详细论述。
|
|
|
|
对数据库的监控非常复杂，不同数据库监控的指标存在差异，我们将共性的指标抽取出来，如下所示。
|
|
|
|
|
|
|
|
|
|
|
|
. 跟踪共享内存中物理日志和逻辑日志的缓冲区的使用率；
|
|
|
|
. 监控磁盘的数据块使用情况以及被频繁读写的热点区域；
|
|
|
|
|
|
|
|
|
|
|
|
下面举一个Oracle资源监控的例子，可以看到重点关注的内容包括内存利用、事件统计、SQL分析、会话统计。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
②shared hash latch upgrades - no wait；
|
|
|
|
③shared hash latch upgrades - wait；
|
|
|
|
④redo log space wait time。
|
|
|
|
|
|
|
|
②table scans（long tables）；
|
|
|
|
③table scans（short tables）；
|
|
|
|
④index fast full scans（full）。
|
|
|
|
|
|
|
|
②session stored procedure space；
|
|
|
|
③CPU used by this session；
|
|
|
|
|
|
中间件服务器包括Web服务器，例如Apache; Web应用服务器，例如Websphere和WebLogic；应用服务器，例如tuxedo等。国产中间件目前也在广泛地使用，例如TongLink、名称等。中间件是客户端负载压力的直接承受者，中间件的资源使用得是否合理，与客户端以及与后台数据库服务器连接是否合理，都直接影响系统的性能。
|
|
|
|
中间件的监控要得到哪些指标的值呢，以及怎样分析结果值，我们在后面章节会有详细的论述。
|
|
|
