XX网站性能测试报告目录XX网站性能测试报告1测试概要2测试用例设计2测试环境与配置3测试执行与记录4首页性能测试策略一：4测试数据收集及分析4调优建议：6首页性能测试策略二：7测试数据收集及分析7测试总结9子系统性能测试策略一：9测试数据收集及分析9子系统性能测试策略二：11测试数据收集及分析11测试总结13测试概要本次测试为性能测试，主要就XXXX网站首页以及三个子系统：销售支持系统、销售员查询系统和意外险查询系统施加压力，以平均事物响应时间为上限，测试系统所能承受的最大用户数以及服务器资源占用情况等指标。
测试用例设计由于主页与三个子系统分属不同的服务器，对主页施加压力不会对web服务器以及数据库服务器造成影响，因此此次性能测试主要分为对主页的压力测试以及对三个子系统的压力测试两大部分。
首页分为七大模块：关于网站、新闻中心、产品博览、客户服务、在线投保、客户留言和加入我们，分析用户习惯设计用例分布如下：首页各模块压力配比：三个子系统：销售支持系统、信息查询系统、营业员查询系统在同一服务器上，混合场景设置配比如下：子系统各模块压力配比：测试环境与配置本次性能测试硬件资源采用将来上线时的服务器，本系统采用B/S架构，用户通过浏览器访问应用系统。
环境主要包括了数据库服务器、应用服务器和压力测试机。 测试结果只适用在本测试环境上参考。
一：公司网站服务器：角色：应用服务器IBM刀片HS22操作系统：Windows2003处理器：2CPU内存：12GIP：XX.XX.XXX.XX二：子系统（个险销售支持系统、信息查询系统、业务员查询系统）应用服务器角色：应用服务器IBM刀片HS22操作系统：RedHatLinux处理器：2CPU内存：12GIP：XX.XX.XXX.XX三：子系统（个险销售支持系统、信息查询系统、业务员查询系统）数据库服务器角色：数据库服务器IBM刀片HS22操作系统：RedHatLinux处理器：2CPU内存：12GIP：XX.XX.XXX.XX四：测试服务器角色：测试服务器DELLPC操作系统：WINXP处理器：2CPU内存：1GIP：XX.XX.XXX.XXIP：XX.XX.XXX.XX测试执行与记录首页性能测试策略一：场景设计：本次测试场景设置根据被测功能点及各功能点的业务分配比例，思考时间将采取录制时间50%~150%随机选取，虚拟用户模拟IE7浏览器访问首页。
为增大对服务器的压力，虚拟用户执行下次循环时作为一个新用户处理，清除上次运行时的缓存；同时重新下载非HTML资源。
压力策略：主要采取模拟混合场景策略，根据实际业务比例分配测试脚本比例，以100为粒度采取逐步加压策略，目标并发用户数3000个，达到目标用户数后再持续执行半个小时左右后
停止全部并发。
测试数据收集及分析首页测试结果概要：整个场景执行4小时21分42秒，最大并发用户数为2900个，总通过事务数为1679844个，失败事务数0个平均事物相应时间曲线图：带宽—用户图服务器资源图：从平均事务响应时间曲线来看，随着并发压力的增大，吞吐量也明显增大，各事务响应时间有明显的上升趋势，打开首页事物上升尤其明显，在1200并发用户数后，各事务响应时间上升更加迅速，打开首页事物相应时间超过三秒。 此时查看带宽资源已经到达极限，而服务器资源仍处于平稳状态，CPU的平均占用率在40%以下，各项指标均在良好运行。 上述场景策略运用了最大带宽以求服务器的负载极限，从场景执行情况不难分析出，网络带宽占满后，虚拟用户的响应时间在等待网络资源方面开销较大，从而对服务器的请求率并没有增加，因此服务器资源一直没有被占满。
从这个方面看，即使在带宽满载的情况下，服务器依然能够轻松承受所有压力；但另一方面也表明网络带宽已成为系统瓶颈。
为此我们单独运行一个用户测试，结果为最大占用带宽200K。
将首页所有图片下载计算大小，结果亦为200K。 在多用户并发的情况下，图片太大直接影响访问速度。 调优建议：经测试，首页图片过大可能为带宽占用过高的主
要原因，当图片很多的时候，减少图片大小是提高下载速度的最直接的方法，建议一些要求不是很高的图片用PNG8格式的图片代替JPEG和GIF（非动画图片），因为PNG8在效果一样的情况下图片大小比后两个格式要小很多。
首页性能测试策略二：场景设计：本次测试场景在考虑带宽限制的情况下充分仿真模拟真实用户对首页的访问，虚拟用户方面将假设访问系统主页的用户有50%为经常访问系统的用户，对于这部分用户来说，系统为其保存缓存以减少客户端重复劳动和下载非HTML资源的效率；另外50%为首次访问系统的新用户，对于这部分用户的设置为系统每次循环都清除缓存，同时重新下载非HTML资源，每组虚拟用户限制最大吞吐量为1M带宽。 各被测功能点及各功能点的业务分配比例依照用例设计，思考时间将采取录制时间50%~150%随机选取，虚拟用户模拟IE7浏览器访问首页。
压力策略：主要采取模拟混合场景策略，根据实际业务比例分配测试脚本比例，以100为粒度采取逐步加压策略，目标并发用户数2000个，达到目标用户数后再持续执行15min左右后停止全部并发。
测试数据收集及分析首页测试结果概要：整个场景执行1小时40分钟25秒，最大并发用户数为2000，成功事务数1476162个，失败事务数0个平均事务响应时间曲线带宽—用户图本次场景设置对每组用户的带宽有最大限制，因此系统在逐步加载虚拟
用户的同时会逐步放开带宽，从平均事务响应曲线来看，由于有50%的用户模拟虚拟经常访问系统的老用户不清除缓存，因此每次刚开始放开加载虚拟用户时响应时间会有稍许上升，但从总体来看，所有事务响应时间较为平稳，且都在3秒以下。 测试总结从以上吞吐量明细表来看，随着并发压力的增大，吞吐量也明显增加，当并发数达到2000时，吞吐量达到最大；从第一个场景的执行结果来看，在不考虑带宽的情况下，服务器可在相当于1200个用户同时访问的情况下保持良好运转。 当并发数达到500时，吞吐达到3M左右，说明4M带宽可以支撑同时500人在线使用。
当并发用户数达到700时，吞吐达到4M左右，说明6M带宽可以支撑同时700人在线使用。
同时，应该看到，系统运行一段时间后，随着经常访问的老用户数的增多，在用户习惯为保存缓存的情况下，响应时间不会明显增加。
子系统性能测试策略一：场景设计：本次测试场景设置根据被测功能点及各功能点的业务分配比例，思考时间将采取录制时间50%~150%随机选取，虚拟用户执行下次循环时作为一个新用户处理，清除上次运行时的缓存；同时重新下载非HTML资源。 压力策略：主要采取模拟混合场景策略，根据实际业务比例分配测试脚本比例，以100为粒度采取逐步加压策略，目标并发用户数1000个，达到目标用户数后再持续执行15min左右后停
止全部并发。
测试数据收集及分析子系统测试结果概要：整个场景执行32分46秒，最大并发用户数为1000个，总通过事务数为357942个，失败事务数2229个平均事务响应时间—用户图错误图事物统计：从事物平均响应时间来看，前期响应时间一直没有发生太大变化，直到从900个并发用户增至1000个并发用户时，发生错误事务，响应时间也陡然增长。
但此时服务器仍处于良好运行状态，手动用IE访问也能打开相应页面。
分析错误统计，发现是负载生成器的TCP/IP端口超时等待所致，由于负载生成器发数据包特别快，服务器也响应特别快，从而导致负载生成器的机器的端口在没有timeout之前就全部占满了，从而出现上述错误。
解决方法：手工调整TCP的timeout。
即让负载生成器在最后一个端口还没有用到时，前面已经有端口在释放了。
子系统性能测试策略二：场景设计：测试场景设置根据被测功能点及各功能点的业务分配比例，思考时间将采取录制时间50%~150%随机选取，虚拟用户执行下次循环时作为一个新用户处理，清除上次运行时的缓存。
同时带宽限制在每组用户0.5M以内压力策略：根据上次场景测试发现，并发用户数在1000以内时的事务平均响应时间平稳
且能够达到要求，因此此次场景同时加载并发用户数1000个，达到目标用户数后持续执行5min左右后停止全部并发。 测试数据收集及分析子系统测试结果概要：整个场景执行5分51秒，最大并发用户数为1000个，总通过事务数为89497个，失败事务数0个平均事务响应时间曲线LINUX服务器资源图带宽—用户图从事务平均响应时间曲线来看，各项事务的平均响应时间均比较平稳，没有出现太大波动，除了打开“销售支持系统_行事历”事务外，其余各项事务平均响应时间都在3秒以下，在限制带宽范围内LINUX服务器也响应良好。
测试总结总体来看，三个子系统的资源部署在1000个用户访问时全部处于平稳状态，基本不存在瓶颈。
但响应时间较长的事务仍是那些下载资源较大的事务，如“销售支持系统_行事历”、“销售支持系统_系统设置”等，但整体来说都在可承受范围内，系统不需要调优。
因篇幅问题不能全部显示，请点此查看更多更全内容