Web系统压力测试方法研究与实践.docVIP

Web系统压力测试方法研究与实践 　　摘 要：Web系统已是当今信息系统开发和部署的主流选择。在大数据时代，性能更是衡量信息系统可靠性的重要指标。文章在对Web系统压力测试方法进行研究的基础上，指出高效压力测试的关键在于测试方案应尽可能接近真实应用负载，给出的项目实践经验很好地验证了这一观点。 　　关键词：Web系统；性能；压力测试 　　1 概述 　　近年来，随着信息化技术的不断发展，Web系统（浏览器/服务器，C/S架构）已经成为了信息系统开发和部署的主流选择。相对于传统的客户端/服务器（B/S架构）信息系统，Web系统具有开发便捷、部署快速和易于维护的特点。同时，因其易于和其他系统及接口协同工作，具备了同时向上向下兼容的特性。如今高速发展的移动互联网，大多数移动客户端软件后台连接的都是Web应用系统。 　　对于任何一个商用信息系统，可靠性要求都是必须考虑的重要问题。对可靠性而言，除了基本的功能性保证，在大数据时代，系统的性能更是不能回避的问题。庞大的用户群以及海量数据给Web应用系统的性能带来了诸多挑战。 　　2 Web系统压力测试方法研究 　　2.1 影响Web系统性能的主要因素 　　作为依托网络部署的系统，除去网络这一相对外部的因素后，影响Web系统性能的自身内在因素主要有以下几方面： 　　用户并发数。并发数是建立在用户量基础上的、反应系统繁忙程度的重要指标。每一个在线用户都会产生到后台服务器的会话连接，对系统CPU、内存、I/O等资源产生开销。在线用户大量累积后一般都会引起系统性能的下降。 　　后台数据量。每一次前台页面访问对应都是后台数据库增、删、改、查操作，其执行返回时间与系统后台数据库的基础数据量直接相关。 　　用户行为。业务逻辑复杂程度及在线用户的行为特点也直接影响着性能。同样数量的在线用户，大面积地进行复杂综合报表查询，与仅仅进行静态页面浏览相比，对系统性能影响的差异是不言而喻的。 　　2.2 衡量Web系统性能的重要指标 　　一方面是系统的响应时间。完整的系统响应时间应该从用户发起前台页面请求算起，涵盖经过网络传输、后台服务器响应请求并返回结果，最终在用户浏览器端完成页面渲染、加载等环节全过程。响应时间是用户可感知的，是系统性能的直观体验。 　　另一方面是系统的吞吐率。吞吐率是系统在单位时间内能够处理的请求数，影响系统吞吐率最直接的因素是系统资源总量和完成单次请求所需的系统资源。在实践中，一般指系统在单位时间内能够成功完成的交易或事务数量。 　　2.3 Web系统主流压力测试工具 　　进行Web系统压力测试，需要高效的工具支持。在商业软件方面，比较著名的产品有Loadrunner（原为Mercury产品，现已被惠普公司收购）、SilkPerformer（Borland公司产品）等；开源软件方面，比较著名的有JMeter、Grinder，以及WebLOAD等。这些产品基本工作方式都是通过“录制-回放”模式来编写压力测试脚本。 　　Web系统压力测试是项目实践工作中最关键的环节，是设计压力测试场景。好的场景设计应尽可能接近真实应用负载，才能充分暴露系统性能瓶颈点，提高测试效率。要做到这一点，项目实施人员需充分认识影响Web系统性能的主要因素，依据业务逻辑设定实际、合理的测试参数。结合高效的测试工具，在测试中密切关注衡量Web系统性能的重要指标，不断修正测试场景，实践一个与系统真实应用负载逐渐拟合的过程。 　　3 项目实践案例 　　作者作为项目负责人，于前期完成了一次Web应用系统建设工作。该项目为全市各商业银行基层网点提供某人民币对公业务网上办理服务。系统使用标准J2EE三层架构设计，为减轻商业银行负担，采取纯B/S架构，不在各商业银行架设前置机服务器，全市2000余家基层网点均采取直连方式（一点接入）访问中心服务器。在上线前测试阶段，为解决系统出现的性能问题，作者带领项目开发人员组织了多轮压力测试。压力测试工作依据如下步骤开展： 　　第一步，排除系统外围因素。网络因素是Web系统自身之外的性能影响因素，但是当出现性能问题时，必须对其影响程度做到心中有数。在不对应用系统做任何调整的情况下，单纯加大并发压力便有了收获，在此环节找到了一个服务器区接入层交换机品牌型号兼容性导致的性能问题。 　　第二步，合理设计测试场景，利用压力测试定位系统性能瓶颈。经与业务需求部门充分交流，作者很快就掌握了该系统的业务访问特点：在每日下午特定访问时段，用户的高频访问全部集中在几个关键页面上。当此“尖峰时刻”到来时，大部分在线用户的行为是在对当日的交易结果进行确认，同时还有相当一部分用户在利用系统日切前的最后机会对交易数据进行补录。系统响应时间随着用户并发量和“尖峰时刻”的临近逐渐增