Ｗｅｂ性能测试方法及其应用

冯行武      G2009225426

摘要：针对Web应用软件的特征，提出了一种基于目标的性能测试方法，其关注的主要内容包括与Web应用相关的负载测试和压力测试两个方面。不但对这两个方面的测试方法进行了全面的分析和探讨，还强调了测试过程管理的重要作用，最后给出了这种方法在Web应用性能测试实践中的一个具体应用。

 　　关键词： 性能测试； 负载测试； 压力测试； 软件测试

　　目前，随着电子商务和电子政务等Web应用的兴起，基于B/S结构的软件日益强劲发展，正在成为未来软件模式的趋势。然而，当一个Web应用被开发并展现在用户、供应商或合作伙伴的面前时，尤其是即将被部署到实际运行环境之前，用户往往会疑问：这套Web应用能否承受大量并发用户的同时访问？系统对用户的请求响应情况如何？在长时间的使用下系统是否运行稳定？系统的整体性能状况如何？如果存在性能瓶颈，那么是什么约束了系统的性能？而这些正是Web性能测试解决的问题，如何有效进行Web性能测试，目前并没有一个系统和完整的回答。此外，由于紧凑的开发计划和复杂的系统架构，Web应用的测试经常是被忽视的，即使进行了测试，其关注点也主要放在功能测试上。但是，近年来Web性能测试越来越引起重视，成为Web系统必不可少的重要测试内容。

 　　本文的研究就是基于这种需求，从已进行过的Web性能测试实践中总结一套基于目标的Web性能测试方法，该方法已在大量的软件测试项目实践中被证明是有效的和可操作的。其具体测试实施方面包括负载测试和压力测试。

1概述

1．1基本概念

 　　一般来说，性能测试包括负载测试和压力测试两个方面: 负载测试是为了确定在各种级别负载下系统的性能而进行的测试，其目标是测试当负载逐渐增加时，系统组成部分的相应输出项，如响应、连接失败率、CPU负载、内存使用等如何决定系统的性能。压力测试是为了确定Web应用系统的瓶颈或者所能承受的极限性能点而进行的测试，其目标是获得系统所提供的最大服务级别的测试。

1．2 Web性能测试的目标

Web性能测试的目标是什么？它不仅是用测试工具去运行一些测试脚本来证明产品是否可以达到性能指标，更关键是要发现产品性能上的缺陷，并解决定位问题，这才是软件性能测试的真正目的。其目标可分为以下两种级别：

（1）性能测试总体目标。找出Web应用系统可能存在的性能瓶颈或者软件缺陷，确认其是否可以达到用户的使用需求。收集测试结果并分析产生缺陷原因，提交总结报告，让软件开发方对Web应用进行性能改进。

 　　（2）性能测试具体目标。此目标又可以分为：

 　　①确定Web应用系统的总体性能参数，包括所支持的最大并发用户数、事务处理成功率、请求相应的往返延迟等。②确定在各个级别的负载及压力测试下服务器输出的具体性能参数。

 　　这些测试目标驱动了整个测试过程的进行，因而在Web性能测试中起着至为关键的核心作用，因此在软件性能测试之前一定要有一份《软件性能测试需求规格说明书》，用于定义详细的测试目标，这是检查软件性能是否符合要求的基本依据。

1．3 基于目标的Web性能测试

系统的负载测试需要采用负载工具进行，真实模拟大量用户访问Web应用系统来测试系统的表现，包括测试静态HTML页面的响应时间，甚至测试动态网页的响应时间等，看是否满足预期的设计指标要求，为服务器的性能优化和调整提供数据依据, 负载测试不会以使系统崩溃为目的，因此负载测试的期望值一般以满足使用需求为主，不需要太夸张的数值。

系统的压力测试也需要使用压力测试工具，主要是对Web服务器进行压力测试。测试可以帮助找到一些大的问题，如死机、崩损、内存泄漏等。因为有些存在内存泄漏问题的程序在运行一两次时可能不会出现问题，但是如果运行了成千上万次后，内存泄漏得越来越多，就会导致系统崩溃。

2 Web应用性能测试环境建立

    目前比较流行的负载测试和压力测试工具有LoadRunner、WebLoad、QALoad、JMetert等，本文就WebLoad的性能测试过程进行讨论。

webload是RadView公司推出的一个性能测试和分析工具,它让web应用程序开发者自动执行压力测试;webload通过模拟真实用户的操作,生成压力负载来测试web的性能。

2.1工作原理

webload提供巡航控制器cruise control的功能,利用巡航控制器,可以预定义web应用程序应该满足的性能指标,然后测试系统是否满足这些需求指标;cruise control能够自动把负载加到web应用程序,并将在此负荷下能够访问程序的客户数量生成报告。

图一 Webload的应用框架

2.2软件安装

双击应用程序，点Next|Yes|Next。

选择安装路径D:\Program Files\RadView\WebLOAD|Next|Next

正在安装

安装完毕

2.3 Webload人通信设置

配置SNMP协议使多个压力机之间互相通信：

在windows里进入[控制面板]->[添加删除程序]->[添加删除windows组件]选择[管理和监控工具]，[下一步]后选择windows安装文件路径，[完成]。

2.4 TestTalk安装

TestTalk在测试会话里监测压力机间的信息传递,如果通信不成功则报错TestTalk自动安装,测试执行时在后台自动运行，注意不要将它关闭。

3 Web应用性能测试流程

3.1 web录制脚本

Webload提供便捷的脚本录制工具，测试人员可以用这个工具来捕捉Web访问行为，这些行为被录制成标准的JavaScript脚本，测试人员可以修改脚本这中的参数来达到预期的测试目的。

3.1.1 创建一个项目：运行WebLoad，首先创建一个项目。

创建项目

3.1.2 开始录制：单击工具条中的按键开始录制脚本，录制脚本的时候会打开一个浏览器窗口，只有在这个窗口内录制的内容才会生成脚本，在这个窗口中输入被测软件的地址：http://www.baidu.com，在IDE中的Script窗口将会生成相应的脚本。

录制生成的脚本

更改数量级到500，再次访问这个地址，从录制脚本的变化，我们可以看出WebLoad自动捕捉了中间的访问间隔Sleep(9356)。

改变访问对象后录制脚本的变化

3.1.3 创建事务：展开左侧的“Load”工具组，拖放“beginTransaction”到第一个URL之前，起名为：“Transaction1”；拖放“EndTransaction”，选择“Transaction1”完成事务的创建。

创建事务后脚本的变化

3. 2　运行测试

3.2.1打开刚才的项目，单击“run test”，对刚才录制的脚本开始进行测试。在执行窗口中可以看两次访问已经被执行了。

事务的执行结果

3.2.2在“Logic View”中可以牛二珠运行善，最后一行显示已经运行通过。

3.2.3 在“Browser View”中可以牛二中大恒基暂不的网页，以及网页的DOM树结构de“HTMLVEW”中可以看到网页的HTML代码；在“HTTP Headers View”中可以看到HTTP的头信息。

访问成功后网页的结构

3.3 进行压力测试

3.3.1 运行WebLoad console，创建一个新模板。压力测试可以只执行单一Agenda测试，也只可以运行多个Agenda一起测试，在本例中选择“Single Agenda”，选择最初保存的Agenda。

创建压力测试模板，执行单一Agenda测试

3.3.2 单击“easurements Manager”添加压力测试的监控器，监控器的不同会导致在压力测试过程中不同的显示输出结果；然后，单击“Add Data Source”添加数据源，本例中选择Windows平台；最后，选择监控主机。

 

3.3.3 选择要监控的性能指标，本例中我们关心的是系统处理时间。

3.3.4 为本次测试选择主机，其中localhost是我们刚创建的测试主机，用它来进行测试。

3.3.5 配置主机在某个时间点进行测试。首先， 单击“Load Profiler”更改压力属性；然后选择总共测试时间为5分钟，开始测试的虚拟机数为1，最终虚拟机数为5；最后，单击“Replace”更新属性。测试属性配置完成后，单击开始测试。

配置主机测试方案

3.3.6 在测试结果中，横坐标为并发用户数量，纵坐标为数值。窗口中默认有4种性能指标：加载大小、每秒单击率、周期时间和吞吐量。单击，可查看数据结果。

查看测试结果

    从统计数字上可以看出，平均加载时间为0.1秒，周期时间为4.8秒，有1个周期等等。

4 Web工具小结

WebLoad中的参数使用非常灵活，能满足实际应用测试的需要。在Web应用测试过程中，不同客户剖端的行为是不同的，因此需要将行为变量化。WebLoad提供了智能拷贝和参数化行为的方法，以模拟出不同行为的多个客户端同时在线的场景。

WebLoad的另一个重要组件是WebLoad Console。WebLoad IDE侧重于脚本的录制及编辑调试等功能，而WebLoad Console侧重于加载生成的脚本。包括：定义Load客户端的策略，例如线性提高、随机变化加载虚拟客户端的数量；设定Load时间，而且可以生成随时间和Load数量的报告，帮助我们找出系统瓶颈；在测试时可以动态加载监视对象，例如响应时间、CPU处理时间、内存占用率等等。

WebLoad的Mix of Agendas可以在一个测试方案中添加多个测试脚本，这样便能模拟多个客户端的使用。例如：我们可以模拟10个客户端在登录，10个客户端在浏览网页，10个客户端在添加商品到购物车，然后每种功能的客户端还在不断地增长，这样的测试方案可以尽量地接近真实的环境。

WebLoad不公可以进行性能测试，而且可以进行功能测试。功能测试的原理是查找相应的HTMLk的信息来判断测试脚本是否成功。例如：如果用户登录失败，我们通过查找，如果发现失败在HTMLr响应文本中，我们就认为测试用例失败了。另外这对HTML的学习也是有帮助的。

最后，WebLoad 与JMeter相比具有如下优点：

1、 JMeter只提供了可视化编辑方式，跟提供的编辑方式相比，WebLoad在创建测试JavaScript脚本方面更加灵活。

2、 JMeter只适用于Java程序，因此不能在测试脚本中调用COM对象。

3、 JMeter比WebLoad支持的服务器监控协议要少。

4、 JMeter不支持对HTTPS网站进行脚本录制。

5、 WebLoad的分析和报告能力要超过JMeter。

5 总结

Web应用的多样性决定了Web性能测试方法的多样性，但无论其表现，所有的测试活动都一定有其目的性，也只有让性能测试围绕其目标展开才能使投入的测试资源产生最大的效益。本文围绕所提出的基于目标的性能测试而展开，同时强调了测试管理的作用，并给出了一个邮件系统测试的实例。本文提出的性能测试方法已经在许多项目实践中得到了良好的应用，但Web性能测试模型的总结和深入研究还有待进一步进行，这也是我们下一步的主要工作计划。

第二篇：一次web性能测试小结

写给新手‐‐一次web性能测试小结?

1?项目背景?.................................................................................................................................?1?

1.1?

1.2?

2?背景介绍?.................................................................................................................................?1?性能测试目的?.........................................................................................................................?1?被测程序分析?.........................................................................................................................?2?

2.1?

2.2?

2.3?影响客户申领性能的主要因素?..............................................................................................?2?程序实现的主要逻辑?.............................................................................................................?2?线上日志分析?.........................................................................................................................?2?3?

4?测试场景设计?.........................................................................................................................?3?测试结果分析?.........................................................................................................................?4?

4.1?

4.2?

4.3?

4.4?

4.5?

4.6?

4.7?

4.8?响应时间分析?.........................................................................................................................?4?WEB服务器资源与数据库服务器资源分析?..........................................................................?5?TOMCAT?BUSY?THREADS分析?.........................................................................................................?5?慢查询分析?.............................................................................................................................?7?数据库内部状态?.....................................................................................................................?8?应用程序中的异常?...............................................................................................................?11?5?小结?......................................................................................................................................?12??

本次测试较为简单，不过麻雀虽小，五脏俱全，正好可以用作性能测试新手参考的例子。??

1 项目背景?

1.1 背景介绍?

客户申领功能是销售系统的一个重要功能，销售人员使用该功能来申领处于申领池中的客户，以进行跟进、签单等后续操作。所有销售人员均可以使用该功能，根据日志，访问高峰会出现在早上10点30分和下午的2点38分左右。?

目前已上线版本中，存在较多的slow?log，本次针对线上问题进行了优化。需要进行相应的性能测试，以确定修改后版本的性能。?

本文对优化的方法不做讨论，只从QA角度讨论进行性能测试的方法。?

1.2 性能测试目的?

测试客户申领功能的响应时间和并发极限?

?

beiyu95@hotmail.combucephalINNODB状态分析?...................................................................................................................?9?usJVM资源分析?.........................................................................................................................?6?

2 被测程序分析?

2.1 影响客户申领性能的主要因素?

? 涉及的数据库表及数据量、索引情况、访问方式?

在CRM的性能测试中，功能涉及的数据库表、数据库表的数据量、索引使用情况至关重要。客户申领涉及的主要数据库表如下：?表名?

Tb_customer?

Tb_follow_assign?数据量?456989?334629?访问方式?读、写?读、写?

2.2 程序实现的主要逻辑?

尽量清楚程序实现的主要逻辑是测试准备的主要功课之一。在知道逻辑的基础上，可以对程序处理数据的方式、使用资源的方式有了比较清楚的把握，了解那些因素会更多的影响性能。?主要涉及如下几方面：?

? 访问的主要数据库表?

? 是否可能存在大量的频繁的堆内存分配（如，记录导出）?

? 是否可能存在大量的SQL拼装（如，各种报表）?

? 其他更多的和性能相关的因素?

2.3 线上日志分析?

对于已经上线的系统，分析系统负载特征的最权威的数据就是访问日志。通过访问日志，我们可以得到：?

? 哪些功能点是访问的最频繁的?

beiyu95@hotmail.combucf.cust_id?not?in?(53041)?and?c.black_flag?=1?and?c.follow_audit=0?limit?3?for?update;??? 并发请求数?不难理解，并发请求是影响性能的主要因素之一，并发数越大，系统负载越大。?ephal?在对索引的使用中，主要是查看索引是否缺失、索引的区分度。尤其是线下构造大量数据时，需要将索引的区分度与线上进行对比。以防止数据的不合理造成索引效率不高等问题呢。?? 客户申领的个数?客户申领的个数在大并发下可能会对性能产生较大影响。从实现上看，申领的个数决定了SQL语句筛选、对记录加锁的范围。如下语句所示，申领个数为3时，会锁定3条记录（这个说法不太准确，根据INNODB行锁实现方式，具体锁定记录数可能会大于3）。?以下是涉及到的核心SQL语句：?select?f.follow_assign_id?follow_assign_id,f.cust_id?cust_id?from?tb_follow_assign?f,tb_customer?c?where?c.cust_id=f.cust_id??and?c.pose_id=11?and?f.follow_id=0??and?us

? 各个主要功能点在系统中访问比例是多大?

? 各功能点访问的响应时间状况如何?

客户申领功能是典型的集中使用功能，会在10点30分、14点28分存在集中访问。根据线上日志分析，在10:30分，一秒之内，申领客户资料的并发请求达到10。20s之内，总请求数达到123。平均申领个数为3，平均响应时间在5s左右。?

us

?

3 测试场景设计?

buc根据本次性能测试的目的。场景设计主要是采用不同用户数（20,40,60,80,100,120）（下图的interactive?schedule?graph显示了不同时段用户数）并发申请3个客户资料。观察响应时间及服务器资源使用。得到不同并发用户数下程序的响应时间，并进一步确定可接受的并发极限。?ephal图1?45秒内访问情况统计??

?

beiyu95@hotmail.com

图2?LoadRunner的压力场景设计?

?

4 测试结果分析?

结果分析是性能测试中难度较大的一环，涉及的因素众多。但也并非无迹可寻，下面以客户申领的性能数据为例，给出了需要分析的各个方面。供大家参考，主要包括：?

? 响应时间?

? 服务器工作状态?

? 每个工作模块压力下的负载?

? 压力下模块间的想好影响?

? 异常/日志分析?

? 深入工作模块内部/底层?

? 操作系统?

? Web服务器内部?

? 数据库服务器内部?

如图所示，在10用户、20用户、40用户、60用户、80用户、100用户并发情况下，随着并发用户数的增加，响应时间略有增加，但响应时间均在10s以下。当120用户并发时，事务响应时间迅速增加，达到100s以上。?

从响应时间上分析，可以初步认为，系统支持的最大并发数为100。（当然，如果想更准确知道是多少，可以进一步测试，比如105。不过意义不大。）?

bucephal4.1 响应时间分析?us

?

图3?响应时间与并发用户数的关系?

?

beiyu95@hotmail.com

4.2 Web服务器与数据库服务器资源分析?

对Web服务器和数据库服务器操作系统级资源的监控，主要包括CPU、内存、网络相关指标。需要重点关注什么指标和系统的应用有关，比如计算密集型的是以消耗CPU资源为主、而有些应用可能是以IO为主。此处，我们可以直接通过分析CPU使用来得到系统基本的性能特点。?

ephalus

?

图4?不同并发用户数下web服务器与数据库服务器CPU使用率对比?

?

从图中可以看出，在100用户以下的并发场景测试中，数据库服务器（944）的CPU使用率一直低于web服务器的CPU使用率，考虑到响应时间很快(结合响应时间图表数据)，可以认为，系统整体运行良好，web服务器和DB服务器协同工作正常，没有明显的瓶颈。?而在120用户并发情况下，数据库服务器CPU使用率要大大高于web服务器CPU使用率(正常是要低于)，而响应时间大大变长。因此，基本说明数据库服务器是系统的瓶颈。?如果要进一步定位出现瓶颈的原因，需要进一步获取数据库的内部状态，如果从数据库内部的监控仍然不能确定原因，可能需要修改代码给出更多的调试信息，以定位问题的原因。?

4.3 Tomcat?busy?threads分析?

Tomcat?busy?threads，即某一时刻tomcat中busy的线程数。比jvm中的线程数更精确的反映了tomcat的繁忙程度与工作状态。Tomcat中通常包括两线程池：?

? http线程池?

tomcat直接提供web访问服务时使用的线程池。?

? ajp线程池?

apache和tomcat之间通过AJP协议协同工作（通过mod_jk），AJP线程池中的busy线程数，准确的反映了tomcat的繁忙程度。?

我们可以通过jconsole监控jvm来获取tomcat?busy?threads相关数据，如下图：?beiyu95@hotmail.combuc

us?

4.4 JVM资源分析?

JVM是web应用服务器运行的基础，对jvm堆内存的监控对于web应用程序非常重要，一般监控如下几个方面即可：?? 内存使用的效率?? GC频率?

? 阈值配置?

? 收集策略?

? 是否存在堆内存泄露的隐患?主要包括以下几个堆内存?? Eden?space(年轻代)?? Survivor?space（中年代）?? Old?space（老年代）??

更多jvm内存结构及垃圾收集机制的信息可以参考java虚拟机手册。下图是以正常运行中的JVM内存状态的例子，包含了丰富的内存状态信息。?beiyu95@hotmail.combucephal图4?Jconsole提供的MBEANS数据?通过查看线程状态，可以进一步确定是哪些线程在工作。比如在tomcat的manager提供的状态查看页面中可以查看当前busy的现场发送的POST/GET请求具体内容。当然，也可以通过分析日志得到，只是不太直观。?

us?图5?Jconsole提供的jvm内存数据状态?

4.5 慢查询分析?

Mysql提供了慢查询日志，可以在my.cnf中打开。通过long_query_time来设置慢查询的阈值。高于该阈值的SQL语句将被打印到慢查询日志中。信息格式如下：?#?Time:?100513?15:48:24?#?User@Host:?crm[crm]?@??[10.81.11.237]?#?Query_time:?2??Lock_time:?0??Rows_sent:?3??Rows_examined:?27517?select?f.follow_assign_id?follow_assign_id,f.cust_id?cust_id?from?tb_follow_assign?f,tb_customer?c?where?c.cust_id=f.cust_id??and?c.pose_id=11?and?f.follow_id=0??and?f.cust_id?not?in?(45064,606760,658815,664398)?and?c.black_flag?=1?and?c.follow_audit=0?limit?3?for?update;?目前，mysql支持设置的阈值最小为1s，如果想设置更小的阈值，需要打额外的补丁。?慢查询是数据库应用性能问题的头号杀手，在CRM类型的应用中更是如此。因此，分析慢查询的原因，找到优化方案是性能优化的重要途径之一。?一般而言，慢查询出现的主要原因可能有如下几个：?? 缺少索引?

? 索引使用不当?? 数据库参数设置不当?? SQL语句的实现导致性能低下?

当然，还有很多其他的原因，比如数据库设计、压力过大、数据存储等等，此处不做展开。?对于慢查询语句的分析，我们可以用explain、profiler等数据库工具进行进一步的分析，查找症结所在。?

beiyu95@hotmail.combucephal

4.6 数据库内部状态?

细心的同学，可以在图?web服务器与数据库服务器CPU使用率对比?中发现，虽然可以判断问题出在数据库上，但数据库本身的CPU?使用率并不高。事实上，通过对数据库操作系统CPU、内存、磁盘IO等的分析后，并没有发现瓶颈的存在。因此，需要了解数据库内部状态，获取压力下数据库层面的性能数据。主要包括：?

? 慢查询?

? INNODB?状态?

? 数据库的逻辑读写?

? 数据库的物理读写?

? SQL执行速率?

? 锁竞争情况?

? 排序状况?

? 临时表?

? 缓存?

当然，数据库的状态参数和配置参数还有很多，可以参考专门的资料。?

下图是一个mysql状态概要数据，通过数据可以看出，mysql的工作负载不是很重，物理IO也比较小。因此，需要进一步分析INNO?DB的内部状态??

bucephalus

?

图6?Spotlight提供的数据库活动概要信息?

上图中各个区分别表明了各类SQL执行的统计、行数据访问的状态、session的状态、缓存的状态、innodb的逻辑读写、数据库的物理读写状态。透过这些性能参数我们可以大致了解数据库的“热点”所在。找到热点后，可以通过更细的指标来查看热点部分的内部工作状态，如排序、锁竞争、mutex竞争等。?

beiyu95@hotmail.com

4.7 INNODB状态分析?

通过show?innodb?status命令，可以查询INNODB的内部状态，mysql提供了异常丰富的信息。通过这些信息，可以掌握innodb内部事务状态、锁状态等重要的性能信息，来辅助性能问题的分析。关于该命令的输出，可以查看mysql手册。?

下面是本次测试锁竞争和死锁的例子。?

4.7.1 锁竞争情况监控?

在大并发下，mysql的锁竞争几乎是不可避免的。锁竞争会导致响应时间大幅变长，系统资源无法充分利用。?

从下面部分输出中可以看出，事务锁定了较多的表，会导致较多的等待，引起系统响应时间变长。?

在发生严重的锁竞争时，mysql处理能力大幅下降，会造成用户响应较慢，从而引起tomat线程数飙升，对系统的稳定性和服务的稳定性造成严重威胁。?

? 锁竞争的例子?

‐‐‐TRANSACTION?0?94611044,?ACTIVE?4?sec,?process?no?28350,?OS?thread?id?1168296288?starting?index?read?

mysql?tables?in?use?10,?locked?10?

LOCK?WAIT?2?lock?struct(s),?heap?size?1216?

MySQL?thread?id?147818,?query?id?5386420?10.81.11.237?crm?Sending?data?

select?f.follow_assign_id?follow_assign_id?from?tb_follow_assign?f,tb_customer?c?where?c.cust_id=f.cust_id??and?c.pose_id=11?and?f.follow_id=0?and?c.quit_user?not?like?'%1981172%'?and?c.black_flag?=1?and?c.follow_audit=0?limit?10?for?update?

Trx?read?view?will?not?see?trx?with?id?>=?0?94611045,?sees?<?0?94611020?

‐‐‐‐‐‐‐?TRX?HAS?BEEN?WAITING?4?SEC?FOR?THIS?LOCK?TO?BE?GRANTED:?

RECORD?LOCKS?space?id?0?page?no?579897?n?bits?1192?index?`Index_follow_assign_follow_id`?of?table?`crm_sale/tb_follow_assign`?trx?id?0?94611044?lock_mode?X?waiting?

Record?lock,?heap?no?636?PHYSICAL?RECORD:?n_fields?2;?compact?format;?info?bits?0??0:?len?4;?hex?00000000;?asc?????;;?1:?len?4;?hex?00015635;?asc???V5;;?

4.7.2 死锁情况监控?

在客户申领的测试过程中，启动了从晚上9点到早上9点共12个小时的压力。在晚上4点11分的时候，置换放弃定时任务启动（Run_Quit_Replacement_Job），由于与客户申领功能发生死锁，导致大量死锁出现，共33次。?

死锁是web系统中较为严重的一类问题，主要的危害有以下几种：?

? 死锁会使进程得不到正确的结果。因为处于死锁状态的进程得不到所需的资源，不能向前推进，故得不到结果。?

? 死锁会使资源的利用率降低。因为处于死锁状态的进程不释放已占有的资源，以至于这些资源不能被其他进程利用，故系统资源利用率降低。?

? 死锁还会导致产生新的死锁。其它进程因请求不到死锁进程已占用的资源而无法向前推beiyu95@hotmail.combucephalus

进，所以也会发生死锁。?

4.7.2.1 LoadRunner给出的错误信息?

当后台发生严重错误时（一般是500错误），LoadRunner?controller中会有错误信息输出。如下图所示。?

ephalus

?

图7?压力工具的错误信息?

系统提示共发生了33次500错误，经排查，和后台的33次死锁信息完全吻合。从此处也可以看出，我们要对发生的500错误，高度重视，找出错误原因，消除潜在的性能隐患。?

4.7.2.2 INNODB的死锁信息?

发生死锁时，Mysql会根据自己的策略，选择一个事务作为牺牲品，回滚该事务。如果程序健壮性不好，可能会造成功能的错误或者用户页面的错误。?

值得注意的是，show?innodb?status只能显示innodb内部死锁的信息，对于多个引擎间产生的死锁无能为力。?

?

下面是INNODB输出的一个死锁信息的例子（部分）：?

LATEST?DETECTED?DEADLOCK?

100512?15:51:23?

***?(1)?TRANSACTION:?

TRANSACTION?0?95431538,?ACTIVE?3?sec,?process?no?28350,?OS?thread?id?1164482912?updating?or?deleting?

mysql?tables?in?use?6,?locked?6?

LOCK?WAIT?21?lock?struct(s),?heap?size?3024,?undo?log?entries?54?

MySQL?thread?id?164143,?query?id?13937709?10.81.11.237?crm?Updating?

update?tb_customer?set?cust_stat_1=3,?cust_stat_2=30,?cust_his_stat_1=8,?cust_his_stat_2=80,?upd_user=1832883,?upd_time=’2010‐05‐12?15:51:22’?where?cust_id=65069?

***?(1)?WAITING?FOR?THIS?LOCK?TO?BE?GRANTED:?

RECORD?LOCKS?space?id?0?page?no?127542?n?bits?976?index?`Index_customer_cust_stat_2`?of?table?beiyu95@hotmail.combuc

4.8 应用程序中的异常?

在实际的性能测试过程中，我们也需要关注应用程序的日志，检查有无异常抛出。以确认压力下系统运行的稳定性与功能的正确性。?

?

? 死锁异常示例?

在上面的访问中，我们从LoadRunner的错误信息，可以查到web服务器的错误日志，通过日志的信息，也可以确认是后台发生了死锁。?

[ERROR]?2010‐05‐12?15:51:20,550?[TP‐Processor58]????????[localhost].[/ht‐callout].[default]?????(StandardWrapperValve.java:253)?–Servlet.service()?for?servlet?default?threw?exception?

com.mysql.jdbc.exceptions.MySQLTransactionRollbackException:?Deadlock?found?when?trying?to?get?lock;?try?restarting?transaction?

????????at?com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1041)?

(以下省略……)?

? 并发访问异常示例?

在有些时候，程序的开发者可能没有考虑到并发访问可能性的存在，对一些不支持互斥访问的数据管理不善，会导致并发访问时产生异常。下面是日志中给出的一个并发访问错误的信息。?bucephalus`crm_sale/tb_customer`?trx?id?0?95431538?lock_mode?X?locks?gap?before?rec?insert?intention?waiting?Record?lock,?heap?no?5?PHYSICAL?RECORD:?n_fields?3;?compact?format;?info?bits?0??0:?len?4;?hex?0000000b;?asc?????;;?1:?len?1;?hex?1e;?asc??;;?2:?len?4;?hex?0000feff;?asc?????;;??***?(2)?TRANSACTION:?TRANSACTION?0?95431550,?ACTIVE?2?sec,?process?no?28350,?OS?thread?id?1179937120?fetching?rows,?thread?declared?inside?InnoDB?497?mysql?tables?in?use?10,?locked?10?4685?lock?struct(s),?heap?size?522224?MySQL?thread?id?164142,?query?id?13937303?10.81.11.237?crm?Sending?data?select?f.follow_assign_id?follow_assign_id,f.cust_id?cust_id?from?tb_follow_assign?f,tb_customer?c?where?c.cust_id=f.cust_id??and?c.pose_id=11?and?f.follow_id=0??and?f.cust_id?not?in?(52355,)?and?c.black_flag?=1?and?c.follow_audit=0?limit?10?for?update?***?(2)?HOLDS?THE?LOCK(S):?RECORD?LOCKS?space?id?0?page?no?127542?n?bits?976?index?`Index_customer_cust_stat_2`?of?table?`crm_sale/tb_customer`?trx?id?0?95431550?lock_mode?X?….?***?WE?ROLL?BACK?TRANSACTION?(2)?

?

beiyu95@hotmail.com

图8?压力下的并发错误日志?

5 小结?

通过4.7.1的分析可以看出，在大并发下，严重的锁竞争导致了瓶颈的出现。测试中使用的是mysql?5.0.25，并发性能方面比较弱。在5.0.47之后并发性能有了较大提高。在CRM的应用中，100并发已经基本可以满足需要，因此暂时可以接受这样的性能结果。?

通过4.7.2的分析，可以看出系统中存在死锁，并导致了事务失败回滚，给应用程序造成异常。改死锁是由表访问顺序不一致造成的。在修改了相关事务逻辑，使不同事务对表的访问顺序一致后解决。?

?

beiyu95@hotmail.combucephalus