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

开篇：润墨网以专业的文秘视角，为您筛选了一篇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系统自身之外的性能影响因素，但是当出现性能问题时，必须对其影响程度做到心中有数。在不对应用系统做任何调整的情况下，单纯加大并发压力便有了收获，在此环节找到了一个服务器区接入层交换机品牌型号兼容性导致的性能问题。

第二步，合理设计测试场景，利用压力测试定位系统性能瓶颈。经与业务需求部门充分交流，作者很快就掌握了该系统的业务访问特点：在每日下午特定访问时段，用户的高频访问全部集中在几个关键页面上。当此“尖峰时刻”到来时，大部分在线用户的行为是在对当日的交易结果进行确认，同时还有相当一部分用户在利用系统日切前的最后机会对交易数据进行补录。系统响应时间随着用户并发量和“尖峰时刻”的临近逐渐增大，性能拐点明显。在性能下降到一定程度后，新用户甚至已经无法登陆系统，在线用户交易请求开始出现大量失败。

根据“场景设计应尽可能接近真实应用负载”的原则，作者在此项目压力测试方案设计中重点考量了用户行为、数据量铺垫以及并发数等几个因素。业务部门提供的需求数据，是数据量铺垫和并发数估算的原始基础；为达到尽可能接近真实的目标，作者对前期全市联调阶段系统后台记录的日志展开深入分析，统计出系统高峰访问时段用户增、删、改、查等具体行为的分布比例，并根据商业银行接入数量、线路带宽等因素进行相应调整，修正场景设计中用户行为的权重。之后利用企业级Loadrunner测试工具，反复录制调试测试脚本。同时采取对应用服务器与数据库服务器分离部署的方法，在压力测试中分别监测操作系统、数据库、应用各部分对应性能指标。

通过几轮压力测试，项目组很快就定位到了影响系统性能的关键问题，并提交开发人员进行对应处置。在应用层面，局部针对性修改代码，对高频访问页面涉及到的数据库基础表做全局内存静态化处理，优化高耗能SQL语句；数据库层面，对涉及复杂查询的业务表进行分表处理，实现当前热数据与历史冷数据的合理隔离；在系统整体集成层面，对操作系统、数据库及应用中间件分别进行参数调优。

通过上述努力，经压力测试优化后的系统再次提交测试，整体性能有了显著提升，“尖峰时刻”的性能拐点已经完全消失，无论从系统的响应时间还是吞吐率指标看，均达到了预期建设目标，并且完全能够支撑未来五年业务发展的性能预留空间。目前系统已投产上线，运行平稳，为全市金融服务水平提升起到了重要推动作用。

4 结束语

性能是信息系统建设和运维中永恒的话题。做好Web系统压力测试，第一要务是在排除外部干扰因素，充分了解业务逻辑的基础上，设计出尽可能接近真实应用负载的测试场景。

要达成这一目标，最重要的是对用户并发数、铺垫数据量以及用户行为的把握，并借助有效的工具软件进行迭代验证。实践经验证明，高质量的压力测试是系统项目建设中进度与质量的重要保证。