WEB性能测试与性能调优总结

前段时间，我们测试团队对新开发的一个数据分析系统进行性能测试与优化工作，期间遇到不少问题，并分析解决问题。

系统从开始的50用户并发都不满足，优化到最终可以支持500以上并发，性能提升至少10倍以上，感觉很有成就感。

在此，把整个经历过程给大家分享一下，文档是对自己这次性能测试进行一次总结。

经过一个多月的性能测试，收获还是很大的，当然，由于自己经验方面不足，定位时间花费比较长，效率有些低。

因此，写了这篇总结文档，分享下，大家一起进步，也希望对更多的测试人员在性能测试上有所帮助。

一、准备：局域网搭建测试环境，系统主要模块，sso登陆、数据报表页面查看、地图展示指标数据、大数据分析与结果报表展示。

系统主要是J2EE、后台数据库使用Oracle与hadoop。

目标是测试该系统能否支持500用户同时并发，每个页面或局部刷新响应时间在2秒左右，且长时间运行稳定，也是对系统性能的一次摸底，找出性能瓶颈并优化二、背景使用浏览器代理方式，输入首页地址http://xxxx由于我们有SSO登陆，因此跳到登陆页面，输入用户名与密码。

然后进入首页，首页有地图，有报表，类似下图：三、生成脚本通过“录制快照”来查看页面HTTP请求，了解我们系统的页面结构，页面时间，即正常浏览器点击到页面显示的时间，每个HTTP的时间与内容长度。

这点也是挺重要的，开始对工具不熟，录制后调通脚本就直接测试，结果发现测试结果有成功有失败，测试结果报告提示脚本时间比录制大，但不知道怎么分析；另外测试发现有些请求时间很大，已经超过10几秒。

然后，测试过程中多次请教了工具的支持人员后，对工具有所了解，也是一些性能测试经验知识。

TPS（Transaction Per Second）即事务，事务是很重要的。

我们测试的其中一个脚本录制的页面有2个页面，一个ajax局部刷新请求，性能测试要从用户的角度来看，即每个页面完成需要在用户可以忍受的时间内，网上说一般是2秒内认为正常，5秒内有点慢但还可以接受；ajax局部刷新也要在合理的时间。

因此，在支持人员的指导下，为脚本配置了3个事务，2个页面分别事务，一个叫login、一个叫main，然后也对ajax请求配置事务report；这样通过工具的统计信息，就可以单独分析login、main与report 3个事务的成功与失败，事务响应时间是否合理，在合理范围内则表示测试通过，如果响应时间大则需要考虑是否合理。

1、录制快照配置了3个事务后，通过录制快照来分析事务的情况可以看到每个事务包括了那些请求，该事务录制时花了多长时间，这个时间是测试结果报告里的录制参照值，测试结果报告的事务时间跟这个值对比就知道是否时间合理。

同时，可以看到脚本包括多少个HTTP请求，后台请求有多少个、图片有多少个，主要时间花费在哪里；每个事务包括多少个HTTP请求，多少个服务器，哪个服务器占用时间比较大。

后面测试时，发现很多问题，也是通过录制快照来分析页面结构，发现请求太多、有些请求没有进行缓存（快照的重复有96个）、图片与JS请求太多，后面进行了合并减少了http请求，也提高了成功率和事务时间。

另外，通过快照里的“并发时间图”来查看每个事务浏览器是怎么并发的，是串行一个一个发送HTTP请求，还是并行多个发送HTTP请求。

这个也非常重要，因为，开始测试时，没有选择模拟浏览器并发，测试出来的事务时间非常大，有的达到几十秒，比正常浏览器点击页面时间2，3秒时间大很多。

后来咨询了工具的支持人员，才知道有并发跟串行的说法，下图可以看到，浏览器基本是并发执行请求的，后来网上了解了浏览器并发原理，还有通过浏览器的F12的网络分析也发现确实是同时并发HTTP请求的。

听工具支持人员说，好像现在其他测试工具是不支持一个虚拟用户并发HTTP请求的，以前用loadrunner也没去研究，不过好像确实测试的时间总比正常浏览器访问要大。

这个后面再确认，如果真是这样的话，那确实工具这点挺好的；因为每个用户的并发与浏览器一样，对服务器的压力就基本类似，测试的结果响应时间也真实反映每个用户的情况，如果是串行的话，时间大了也不知道怎么分析。

2、脚本调试脚本录制后，开始测试前需要对脚本进行调试。

回放、关联、参数化、验证脚本；通过工具提供的帮助知道文档和支持人员的交流，脚本顺利调试通过，也通过后台数据库和工具的验证页面功能查看，脚本通过。

OK，下面开始性能测试和结果分析、调优了。

四、第一阶段测试开始没配置login、main与report 3个事务，也没配置模拟浏览器并发，调试通过后就直接跑，可能是自己对性能测试经验不足，不知道配置事务这么重要。

同时并发50个用户，看下怎样结果测试多次的结果，有时都成功，有时存在2，3个用户失败，但脚本执行时间居然80%以上达到将近50秒，2个页面一个ajax局部刷新，正常使用浏览器时，也才几秒，应该不可能达到这么大啊。

测试时，自己使用浏览器访问页面，有时地图加载失败，有时成功，页面出来也比平常慢。

懵了，怎么定位呢，经验严重不足。

先从工具提示与统计来分析，再加上请教了工具的支持人员，也学到了一些分析方法。

工具汇总报告如下：查看“用户详情”的“用户与事务统计”如下：可以发现80%用户总时间达到47秒左右，但录制时使用浏览器整个时间才7820毫秒，即录制值，相差非常大。

查看“脚本请求统计”分析HTTP请求，如下图：查看每个HTTP请求的统计信息，最大响应时间、90%、80%时间。

这里支持点击列排序即可以找出时间最大的HTTP请求有哪些。

点击“详细分析”查看更细分的统计，可以按域名、HTTP类型等分析其中，访问google有两个请求时间比较长，另外，界面下面给出域名占总时间比例还是比较大，因此可以确认访问google是一个瓶颈点，工具用到google地图。

在“脚本请求统计”界面的滚动条拉下来可以看到，有哪些请求失败，失败原因是什么，下面是50用户都成功时的统计，显示TCP建立时间超过3秒，表示这些请求响应时间太大，应该是TCP建立时间长导致。

如果这里有其他失败，也可以看到统计，很方便分析。

根据根据分析，初步确认google的请求时间比较大，那为什么会大呢，需要定位找原因并解决，由于自己在性能测试经验上欠缺，问了工具的客服人员，说可能是网络原因，汇总报告里也提示建立TCP时间长可能是网络原因。

OK，咨询我们的网络人员，网络人员给了个Ping如下：正在Ping [64.18.0.10] 具有32 字节的数据:来自64.18.0.10 的回复: 字节=32 时间=542ms来自64.18.0.10 的回复: 字节=32 时间=420ms来自64.18.0.10 的回复: 字节=32 时间=511ms来自64.18.0.10 的回复: 字节=32 时间=480ms发现测试环境到google服务器的网络时延比较大，达到500多毫米。

另外，分析访问SSO 服务器的HTTP也时间也比其他HTTP长，但比google时间要小一些。

网络人员给出的解释是，因为公司网络到SSO服务器和到google服务器的带宽比较小，而且是办公网络，当前是办公时间，大家都在使用网络。

SSO服务器网络原因解决办法比较容易，让网络人员对测试环境的网络做一些配置；而google响应慢与开发交流，先不理，后面可能会专门开发个缓存代理，不用每次都去google访问。

所以，测试脚本中把google的HTTP请求删除掉，目前测试我们自己服务器，先不管google。

五、第二阶段测试为脚本配置了3个事务，目的是从事务的响应时间来分析页面或局部刷新的时间是否合理；2个页面分别事务，一个叫login、一个叫main，然后也对ajax请求配置事务report；前面通过修改网络和删除google地图相关HTTP请求，响应时间提升了10多秒。

但还是40秒左右，离我们目标每个页面2-5秒范围相差很大。

测试过程在同事电脑上使用浏览器访问页面，也还是很慢，证明系统可能有瓶颈。

怎么优化呢，第二阶段与第三阶段性能测试耗时最长的优化就是这阶段，也是最具有挑战性的阶段。

发现了很多问题，通过优化，性能提升很大。

网上查资料、看论坛，大概意思就可能是网络原因、数据库原因、CPU、内存的；OK，在测试时添加服务器监控，在工具controller界面添加服务器、数据库内存与CPU监控，配置添加monitor监控器运行结果发现tomcat的CPU与内存很低，但数据库CPU在查询时有点彪升，因为页面涉及到地图数据、报表数据都需要访问数据库。

通过工具详情分析里的HTTP后台动态类型分析，部分HTTP请求时间比较大与开发交流，开发团队给出了解决方案，增加redis缓存，把一些常用不改变的数据，如地图边界、常用报表在tomcat启动时就加载到缓存，另外，把数据库查询结果保存到缓存，如果是一样的查询语句，则直接从缓存读取，减少到数据库查询，提高效率，终于把后台数据库查询的HTTP请求时间降下来。

六、第三阶段测试1、脚本修改为模拟浏览器并发上面通过redis缓存解决了后台数据库并发性能差的问题，响应时间得到大幅下降，总的响应从40多秒时间降到20秒左右，3个事务响应时间分别在6，9，5左右。

多次测试仍然还是20秒，但测试过程使用浏览器访问页面都正常，页面出来时间也大概1，2秒时间。

经验不行，不懂怎么办了。

此次测试是摸底系统是否可以支持500用户数并发，即页面访问都成功、而且每个页面或局部刷新响应时间在2-5秒范围内；现在每个HTTP请求，都比较合理，与录制值比较相差不大，但每个事务时间在8秒左右，总时间20秒左右，以为系统无法支持500用户；咨询工具支持人员，原来脚本没配置“模拟浏览器并发”，然后启用“模拟浏览器并发”终于把时间降下来，降到10秒左右，login事务对应页面、main事务对应页面，局部刷新事务report的响应时间都在3秒左右，正常范围，50个用户通过。

为什么要“模拟浏览器并发”，问了工具的支持人员，原理大概是我们使用浏览器访问页面时是并发的，可以通过浏览器的F12调试工具的网络查看页面的HTTP请求；网上搜索了下，好像一个域名可以同时并发6个请求，那我们系统有多个域名，至少6个并发以上；如果没有配置“模拟浏览器并发”工具执行脚本时是串行一个一个HTTP执行，那当然比正常浏览器慢。

另外，工具串行500个并发比浏览器500个并发压力不是一个量级，可能相差好几倍。

如252辆车（252个HTTP请求）要到达目的的，一个是一车道（串行）还堵车(阻塞)，一个是6车道（并行），时间差别很大，对服务器压力也差别大。

2、逐步提高并发用户从并发50用户数，慢慢提升到并发100、150、200、250、300、400、500用户数。