转：Web网站性能测试分析及调优实例

　一、背景

　　前段时间， 性能测试团队经历了一个规模较大的门户网站的性能优化 工做，该网站的开发和合做涉及多个组织和部门，并且网站的重要性不言而喻，同时上线时间很是紧迫，关注度也很高，因此对于整个团队的压力也很是大。

　　在此，把整个经历过程给你们分享一下，包括了主要包括了如何使用性能测试的压测工具，压测前的性能问题评估，以及压测执行后的性能问题分析、瓶颈定位。

　　该门户网站的服务器是放在华通和阿里云的平台上的，因此对华通和阿里共建的云平台安全及应急措施方面要求很是高，须要团队给予全力的保障和配合。

　　性能测试（Performance Testing）是集测试机管理、测试脚本管理、测试场景管理、测试任务管理、测试结果管理为一体的性能云测试平台，能够帮助您全方位的评估云上系统性能。

　　本次优化主要是使用了该测试平台服务对客户搭建在ECS上的服务器进行多种类型（性能测试、负载测试、 压力测试、稳定性测试、混合场景测试、异常测试等）的性能压测、调试和分析，最终达到知足指望预估的性能目标值，且上线后在高峰期知足实际的性能和稳定要求。

　 　二、术语定义

　　在介绍项目经历以前，再明确一下测试当中用到的专业指标术语定义，包括但不只限于如下：

　　PV: 即PageView, 即页面浏览量或点击量，用户每次刷新即被计算一次。咱们能够认为，用户的一次刷新，给服务器形成了一次请求。

　　UV: 即UniqueVisitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次。

　　TPS:TPS(Transaction Per Second)每秒钟系统可以处理的交易或事务的数量，它是衡量系统处理能力的重要指标。

　　响应时间: 响应时间是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。

　　VU: Virtual user，模拟真实业务逻辑步骤的虚拟用户，虚拟用户模拟的操做步骤都被 记录在虚拟用户脚本里。通常性能测试过程当中，通俗称之为并发用户数。

　　TPS波动: 系统性能依赖于特定的硬件、软件代码、应用服务、网络资源等，因此在性能场景执行期间，TPS可能会表现为稳定，或者波动，抑或遵循必定的上升或降低趋势。咱们用TPS波动系数来记录这个指标值。

　　CPU: CPU资源是指性能测试场景运行的这个时间段内，应用服务系统的CPU资源占用率。CPU资源是判断系统处理能力以及应用运行是否稳定的重要参数。

　　Load: 系统正在干活的多少的度量，队列长度。系统平均负载，被定义为在特定时间间隔（1m，5m，15m）内运行队列中的平均进程数。

　　I/O: I/O可分为磁盘IO和网卡IO。

　　JVM: 即 java虚拟机，它拥有本身的处理器、堆栈、寄存器等，还有本身相应的指令系统。Java应用运行在JVM上面。

　　GC: GC是一种自动内存管理程序，它主要的职责是分配内存、保证被引用的对象始终在内存中、把不被应用的对象从内存中释放。FGC会引发JVM挂起。

　　网速: 网络中的数据传输速率，通常以Byte/s为单位。经过ping延时来反映网速。

　　流量: 性能测试中，通常指单位时间内流经网卡的总流量。分为inbound和outbound，通常以KB为单位。

　　 三、评估

　　本次性能测试过程的参与人包括了阿里云应急保障小组等多部门人员，网站为外部供应商开发，阿里云提供云主机和 技术支持。

　　该网站以前前期也由其余部门作了验收工做，进行了完整的性能测试，报告显示，性能较差，第一次测试，网站并发数没有超过35个，第二次测试，网站上作了优化后，静态页面缩小后，并发用户数100内 5s ，200内 90%响应在15s以上，随着并发用户数的增长，页面响应最高可到20多秒，并且访问明显感受较慢，因此联系了阿里云的技术支持，但愿可以帮助诊断性能问题，给出优化建议。

　　通过会议讨论后，评估出最终的测试目标：带页面的全部静态资源一块儿，响应时间必须小于5秒，同时并发访问用户数最低500，TPS根据实际的结果来得出。

　 　四、性能测试目标

　　· 并发用户数：>=500

　　· 业务响应时间：<5秒

　　 五、分析

　　经过性能测试前端分析工具(未开放)分析，页面的响应时间88%左右都是消耗在前端资源加载上，服务器端消耗只占到了页面响应的12%左右;

　　一个网站的响应通常由四部分时间组成，前端、网络、服务器和 数据库，前端主要是减少页面大小，减少页面请求数，优化页面js等，网络主要是使用CDN，优化链接数等，服务器主要是优化Apache，优化Tomcat，优化java代码等，数据库是优化sql语句，优化索引，优化数据存储等。

　　 六、测试和优化

　　6.一、页面前端分析及优化

　　咱们对页面的优化仍然从前端开始，首先经过性能测试的前端测试工具（未开放）进行扫描，咱们发现如下问题并优化：

　　· Js较大，无压缩，同时存在重复请求，最多一个js加载4次，已作压缩和减小。

　　· Js位置不合理，阻碍页面加载。

　　· 外部css 考虑本地实现，减小调用

　　· Banner 背景图片较多，无压缩，建议合并

　　· 页面1的后台.do有4个，减小为3个

　　· 页面2的后台do有 2个，减小为1个

　　· 存在加载失败连接，404失败，同时次数很是多，更换为cnzz

　　· 页面加载外部资源失败 (qq等)，且不稳定

　　· 分享功能比较慢

　　· 外部资源建议异步实现，目前所有是jquery渲染，iframe嵌套，时间资源限制，后期优化

　　· 尽可能减小或者不使用iframe

　　页面请求数太多，主要是js和css重复加载问题和图片较小致使的。 通过以上修改及配置服务器静态资源缓存后，性能提升25%，首页响应从1.5秒提升到1.1秒，而且前端优化持续进行。

6.二、服务端优化

　　通常核心页面都要求在300毫秒如下，非核心页面要求在500毫秒如下，同时重点关注并发时的负载和稳定，服务器端代码和响应的快速稳定是整个页面性能的重点。

　　 6.2.一、脚本编写及场景构造

　　根据前期需求评估的内容，客户是一个门户网站，主要由不一样功能页面组成的，各个功能页面当中又包含了静态内容和异步动态请求，因此，性能测试的脚本的编写主要涵盖了各页面的请求和相关静态资源的请求，这里存在一个串行和并行的概念：

　　串行：请求的页面和页面当中的静态资源、异步动态请求组成一个同步请求，每个内容都做为一个事务（也能够共同组成一个事务，分开事务的好处是能够统计各部分的响应时间），这样压测任务执行时，线程就会根据事物的顺序分布调用执行，至关于一个页面的顺序加载，弊端是没法模拟实际IE的小范围并发，但这样测试的结果是最严格的。

　　并行：各个页面以前可使用不一样的任务，采用并行的混合场景执行，同时设置必定的比例（并发用户数），保证服务器承受的压力与实际用户访问类似。

　　场景并发用户数：常常会遇到“设置多大并发用户数合适？”的问题，由于在没有任何思考时间的时候，咱们有一个简单的公式：

　　VU（并发压测用户数） = TPS（每秒执行事务数） × RT（响应时间）

　　因此，在寻找合适的并发用户数上，建议使用性能测试的“梯度模式”，逐渐增长并发用户数，这个时候压力也会愈来愈大，当TPS的增加率小于响应时间的增加率时，这就是性能的拐点，也就是最合理的并发用户数；当TPS再也不增加或者降低时，这个时候的压力就是最大的压力，所使用的并发用户数就是最大的并发用户数。若是此时的TPS不知足你的要求，那么就须要寻找瓶颈来优化。以下图演示的一个性能曲线：

　　· a点：性能指望值

　　· b点：高于指望，系统安全

　　· c点：高于指望，拐点

　　· d点：超过负载，系统崩溃

　　注意：使用外网地址压测可能会形成瞬时流量较大，形成流量计费，从而产生费用，建议可使用内网地址压测，避免损失。

　 　6.2.二、第一阶段

　　在按照客户提供的4个URL请求构造场景压测之后，同时根据实际状况和客户要求，使用性能测试，构造相应的场景和脚本后，模拟用户实际访问状况，而且脚本中加上了img、js、css等各一个的最大静态资源：

　　· 条件：5台ECS机器，200并发用户数，一个后台页面加3个静态页面（共150K）

　　· 结果：静态4000TPS，动态1500TPS，服务器资源：CPU 98%

　　分析和优化：

　　服务器资源消耗较高，超过75%，存在瓶颈，分析平台显示：

　　· 分析发现原来是apache到tomcat的链接等待致使，现象是100个并发压测，就有100个tomcat的java线程，并且所有是runnable的状态，轮询很耗时间。

　　· 同时发现用户使用的是http协议，非ajp协议，不过这个改动较大，须要使用mod_jk模块，时间缘由，暂缓。

　　解决方法：修改了Apache和tomcat的链接协议 为nio协议，同时去除ssl 协议。Tomcat链接数据库池由30初始调整为300，减小开销

　　&lt;Connectorport="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"

　　connectionTimeout="20000"

　　redirectPort="8443" /&gt;

　　 性能对比：

　　· 再进行1轮压测含动态含静态文件，TPS可以从1w达到2.7W，性能提升将近3倍，而且tomcat的线程从原来的200跑满，降到100附近而且线程没有持续跑满，2.6W TPS时候CPU在80%附近

　　· 发现机器的核数都是2核，8G内存，对于CPU达到98%的状况，CPU是瓶颈，而对于应用来讲比较浪费，因此将2核统一升级为4核。

　　· 扩展机器资源，从目前的4台扩到6台，同时准备4台备份，以应对访问量较大的状况。

　　 思考和风险：

　　· 异步请求处理:客户所提供的url都是html静态，虽然页面当中含动态数据，但分析后发现动态数据都是经过jquery执行而后iframe嵌套的，因此不会随着html文件的加载而自动加载，须要分析全部的动态页面，同时压测，这是页面存在异步请求须要关注的地方。

　　· Iframe:Iframe嵌套页面的方式优势是静态资源调用方便、页面和程序能够分离，可是它的缺点也显而易见，包括样式、脚本额外注入，增长请求等等；还有搜索引擎搜素不到内容；iframe建立比其余元素慢1~2个数量级；资源重复加载；iframe会阻塞页面加载，阻塞onload事件；占用主页链接池；html5再也不支持。因此建议尽可能不要使用或者少使用。

　　· [font='Times New Roman']: 脚本录制和模拟实际用户访问。当用户的图片、javascript、CSS等静态资源和后端代码在同一台服务器上时，须要模拟用户的实际访问请求，压测脚本涵盖全部连接和资源。那么使用脚本录制功能就能够采集更全更完整的脚本。

　 　6.2.三、第二阶段

　　找到几个页面的全部动态资源后，整合成为一个事务，串行访问，同时并发压测，从而对纯服务器端进行压测，测试结果以下图：

　　性能分析：页面一和页面二的响应时间分别达到了5秒和2秒，性能较差，总体TPS只有11

　　 性能分析：

　　分析发现响应时间高的缘由主要在RDS数据库上，数据库此时的CPU已经达到100%，处理较慢，怀疑跟sql有关，分析慢sql。

　　 优化方法：

　　数据库第一批优化完毕，优化了6条sql语句以前5s左右，优化后在150ms左右，数据库的QPS 从1k上升到6k。

　　 RDS优化内容包括：

　　优化点主要是调整慢sql的索引，部分sql须要调整表结构和sql写法，须要应用配合才能完成优化，优化前QPS在1000左右，优化后QPS到达6000

　　前端响应时间从5秒下降到150毫秒，前台TPS由150提高到1500.总的TPS能够达到2000。

　　 6.2.四、第三阶段

　　经过性能测试模拟用户实际访问状况，包括全部静态资源，评估出当响应时间小于5秒的时候，最大支撑的并发用户数。

　　测试结果：

　　能够看到，全部的事务RT加起来小于5秒的状况下，并发用户数能够达到3000(6个事务，6个脚本，每一个脚本500)，远远知足项目500个并发用户的目标。

　　总结：

　　 6.2.五、第四阶段

　　评估其余非主站应用的性能以及含静态页面的其余5个页面内容，包括：

　　· 搜索压测

　　· 操做压测

　　· 登陆压测

　　· 证书登入

　　· 针对5个经常使用场景进行混合压测

　　测试结果:

　　发现的风险和问题：

　　· 测试发现，流量存在很是明显的波动，不通过某模块就无此问题，发现有大量的reset链接，会诊后总结：端口复用致使的问题。FULL NAT模式和LVS存在兼容性问题。最终结果: 因为存在兼容性问题，影响到网站的稳定性和性能，暂时加载该模块，待问题解决后再加。先使用另一个模块代替

　　· 凌晨2点，针对单点用户登入进行了压测，发现100并发，该业务接口已宕机，分析结果:Cache缓存设置过小，1G内存容量致使内存溢出，已建议修改成4G。使用http协议性能不佳，早上4点30进行少许代码优化后，业务直接不可用，环境出现宕机没法修复，咱们快速进行快照恢复，5分钟内恢复3台业务机，云产品的优点尽显。用户log日志撑满系统盘，而且一直不知这台云主机还有数据盘，产品上咱们要作反思。帮助用户已进行挂盘及日志迁移至数据盘，减小单盘的IO压力。

　　· Web服务器数据同步，发现服务器io和cpu压力过大。加入inotify机制，由文件增量同步，变动为文件系统的变化通知机制。将冷备及4台备用web机器使用该方式同步，目前，查看内容分发主机IO和CPU使用率已回复正常范围同步推送时间，根据服务器的负载，进行调整同步时间。今天已修改成2分钟。 因为备分量大，晚上进行全量同步。新增4台备用机，已关闭apache 端口 自动从slb去除，做为冷备

　　· 因为目前单点用户登入入口存在架构单点宕机风险，进行登入和未登入风险验证，确认，如用户已登入后，登入业务系统出现宕机，进行简单的页面点击切换，不受影响

　　· 内存优化

　　按照JVM内存管理模式，调整系统启动参数，若是一台ECS部署一台服务器，建议不要选择默认的JVM配置，应该设置内存为物理内存的一半，同时设置相应的YTC和FGC策略，观察Old区变化，避免大量Full GC，建议Full GC频率大于1小时，同时GC时间小于1秒钟。

　 　6.三、架构优化

　　单点登陆服务修改成SLB

　　检索 修改成 SLB

　　内容管理云平台云服务器实现行文件差别同步，同时冷备

　　新增4台web机器

　 　七、总结

　　备注：服务器的CPU达到100% 这实际上是一个好的现象，说明咱们的逻辑所有已经走到了资源消耗上，而不是由外部其余逻辑限制或blocked，这种现象带来的好处就是，首先咱们能够集中精力从减小代码的资源消耗上解决问题，带来性能的改善，其次，实在没法优化咱们也能够增长机器台数，横向扩展来让性能成倍的提升，这也是用成本换性能的方法。固然，前提是架构上支持负载均衡的分布式架构。

　　总的来讲就是，这种状况要不选择从纵向优化，或者选择从横向扩展，均可以增长。

　 　八、遗留问题

　　时间缘由，测试页面有限，有些页面没有测试覆盖到，好比后台页面。

　　登陆系统存在内存风险，因为用户的缓存信息仍然存在单点问题，因此风险较大，同时系统压力不知足要求，并发较高存在crash风险，将来得及发现瓶颈所在。完全解决必须使用OCS等缓存系统改造，同时优化数据库。

　　Iframe框架形成用户体验很差，须要改掉，换成异步js接口方式。

　　后台同步系统，对于资源消耗影响较大，须要持续优化。

　　平台应该提供开发和测试进行自主压测、分析、评估，同时提供统一的测试报告，保证各部分模块的性能，整合起来才能保障整个门户网站的性能。

　　CPU优化还须要继续分析跟进，目前只是增长机器资源下降风险，成本较高。

　　上线发布应该具有统一的回归验证机制，而且平常须要持续优化，避免因为后期代码的改动致使性能降低。

 

 

 原文地址：http://www.51testing.com/html/59/n-3713159.html