LoadRunner性能测试：200并发实战分析与结果

"这篇文档是关于使用LoadRunner进行性能测试的实际操作记录，主要涉及催收系统的失联修复、催记写入接口以及案件详情界面的并发测试和稳定性测试。测试环境包括10.7service层、10.8数据库pg和10.9consumer。在200并发用户情况下设定了响应时间和资源使用率的目标，并对优化后的性能进行了记录。开发团队针对服务接口线程池、SQL查询和服务器性能进行了优化，调整了并发数量至400。测试结果显示，失联修复和催记写入接口在一定并发量下基本达到目标，但案件详情界面的响应时间和稳定性存在问题，需要进一步优化。" 本文档详细阐述了性能测试的过程和结果分析。首先，测试目的是评估催收系统在不同场景下的性能，包括并发用户数的响应时间、CPU使用率、内存占用、磁盘I/O和网络带宽。测试环境配置为10.7服务层、10.8 PostgreSQL数据库和10.9 consumer。设定的性能指标是90%事务响应时间不超过3秒，CPU使用率低于80%，磁盘I/O低于30%，网络带宽占用也需控制在30%以内。 开发团队通过优化线程池配置、SQL查询和服务器性能来提升系统性能，如对mujin-collection-assignee-consumer和mujin-collection-outer-service服务接口进行调优，优化mujin-database数据库的SQL查询，以及增强广州加密接口的服务器性能。此外，将服务间的并发数量调高到400。 测试结果显示，在200并发用户的情况下，失联修复接口的90%事务响应时间在2.48秒，满足3秒内的目标；而400并发用户时，响应时间变为3.851秒，仍低于5秒的阈值。对于催记写入接口，200用户并发12小时后，90%事务响应时间约为3.774秒，75%响应时间在3.07秒，但500w案件量下，之前的优化可能不足以满足需求。案件详情界面的表现不佳，90%事务响应时间达到了24.862秒，且稳定性问题明显，吞吐量与响应时间的关系图显示了这一不稳定状况。 根据以上数据，可以看出失联修复和催记写入接口在当前并发量下表现相对稳定，但案件详情界面的响应时间和系统稳定性需要进一步改进。这可能涉及到界面渲染、数据处理或数据库查询效率等问题，需要针对性地进行优化。同时，测试过程中收集的CPU、内存、I/O等资源使用情况也是评估系统负载和容量的关键指标，有助于识别性能瓶颈，指导后续的系统优化工作。