门户类网站性能测试分析及调优

2024-05-01 04:32

本文主要是介绍门户类网站性能测试分析及调优,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

转自阿里云:https://help.aliyun.com/document_detail/pts/test-case/PTS-TC08-ProtalWebSites.html?pos=1

1 背景

  前段时间,性能测试团队经历了一个规模较大的门户网站的性能优化工作,该网站的开发和合作涉及多个组织和部门,而且网站的重要性不言而喻,同时上线时间非常紧迫,关注度也很高,所以对于整个团队的压力也非常大。
  在此,把整个经历过程给大家分享一下,包括了主要包括了如何使用性能测试的压测工具,压测前的性能问题评估,以及压测执行后的性能问题分析、瓶颈定位。
  该门户网站的服务器是放在华通和阿里云的平台上的,所以对华通和阿里共建的云平台安全及应急措施方面要求非常高,需要团队给予全力的保障和配合。
  性能测试(Performance Testing)是集测试机管理、测试脚本管理、测试场景管理、测试任务管理、测试结果管理为一体的性能云测试平台,可以帮助您全方位的评估云上系统性能。

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

2 术语定义

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

  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为单位。

3 评估

  本次性能测试过程的参与人包括了阿里云应急保障小组等多部门人员,网站为外部供应商开发,阿里云提供云主机和技术支持。
  该网站之前前期也由其他部门做了验收工作,进行了完整的性能测试,报告显示,性能较差,第一次测试,网站并发数没有超过35个,第二次测试,网站上做了优化后,静态页面缩小后,并发用户数100内 5s ,200内 90%响应在15s以上,随着并发用户数的增加,页面响应最高可到20多秒,而且访问明显感觉较慢,所以联系了阿里云的技术支持,希望能够帮助诊断性能问题,给出优化建议。

测试业务并发用户数平均响应时间(秒)90%响应时间(秒)
首页浏览10012.08215.289
 20023.94929.092
分页浏览1008.97312.343
 20018.84624.106

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

4 性能测试目标

  • 并发用户数:>=500
  • 业务响应时间:<5秒

5 分析

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


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


6 测试和优化

6.1 页面前端分析及优化

  我们对页面的优化仍然从前端开始,首先通过性能测试的前端测试工具(未开放)进行扫描,我们发现以下问题并优化:

  • 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.2 服务端优化

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

6.2.1 脚本编写及场景构造

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

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

  并行:各个页面之前可以使用不同的任务,采用并行的混合场景执行,同时设置一定的比例(并发用户数),保证服务器承受的压力与实际用户访问相似。

  场景并发用户数:经常会遇到“设置多大并发用户数合适?”的问题,因为在没有任何思考时间的时候,我们有一个简单的公式:
      VU(并发压测用户数) = TPS(每秒执行事务数) × RT(响应时间)

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

  • a点:性能期望值
  • b点:高于期望,系统安全
  • c点:高于期望,拐点
  • d点:超过负载,系统崩溃

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

6.2.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.3 第二阶段

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


  性能分析:页面一和页面二的响应时间分别达到了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.4 第三阶段

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

  • 测试结果:

                          

  可以看到,所有的事务RT加起来小于5秒的情况下,并发用户数可以达到3000(6个事务,6个脚本,每个脚本500),远远满足项目500个并发用户的目标。
  

  • 总结:

                  

6.2.5 第四阶段

  评估其他非主站应用的性能以及含静态页面的其他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.3 架构优化

  • 单点登录服务修改为SLB
  • 检索 修改为 SLB
  • 内容管理云平台云服务器实现行文件差异同步,同时冷备
  • 新增4台web机器

7 总结

                  

  备注:服务器的CPU达到100% 这其实是一个好的现象,说明我们的逻辑全部已经走到了资源消耗上,而不是由外部其他逻辑限制或blocked,这种现象带来的好处就是,首先我们可以集中精力从减少代码的资源消耗上解决问题,带来性能的改善,其次,实在无法优化我们也可以增加机器台数,横向扩展来让性能成倍的提高,这也是用成本换性能的方法。当然,前提是架构上支持负载均衡的分布式架构。
  总的来说就是,这种情况要不选择从纵向优化,或者选择从横向扩展,都可以增加。

8 遗留问题

  • 时间原因,测试页面有限,有些页面没有测试覆盖到,比如后台页面。
  • 登录系统存在内存风险,由于用户的缓存信息仍然存在单点问题,所以风险较大,同时系统压力不满足要求,并发较高存在crash风险,未来得及发现瓶颈所在。彻底解决必须使用OCS等缓存系统改造,同时优化数据库。
  • Iframe框架造成用户体验不好,需要改掉,换成异步js接口方式。
  • 后台同步系统,对于资源消耗影响较大,需要持续优化。
  • 平台应该提供开发和测试进行自主压测、分析、评估,同时提供统一的测试报告,保证各部分模块的性能,整合起来才能保障整个门户网站的性能。
  • CPU优化还需要继续分析跟进,目前只是增加机器资源降低风险,成本较高。
  • 上线发布应该具备统一的回归验证机制,并且日常需要持续优化,避免由于后期代码的改动导致性能下降。

这篇关于门户类网站性能测试分析及调优的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/950725

相关文章

Vue3 的 shallowRef 和 shallowReactive:优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉,那么对 shallowRef 和 shallowReactive 是否了解呢? 在编程和数据结构中,“shallow”(浅层)通常指对数据结构的最外层进行操作,而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素,而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层(Shallow) 定义

性能测试介绍

性能测试是一种测试方法,旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试,可以确定系统是否能够满足预期的性能要求,找出性能瓶颈和潜在的问题,并进行优化和调整。 发现性能瓶颈:性能测试可以帮助发现系统的性能瓶颈,即系统在高负载或高并发情况下可能出现的问题

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

字节面试 | 如何测试RocketMQ、RocketMQ?

字节面试:RocketMQ是怎么测试的呢? 答: 首先保证消息的消费正确、设计逆向用例,在验证消息内容为空等情况时的消费正确性; 推送大批量MQ,通过Admin控制台查看MQ消费的情况,是否出现消费假死、TPS是否正常等等问题。(上述都是临场发挥,但是RocketMQ真正的测试点,还真的需要探讨) 01 先了解RocketMQ 作为测试也是要简单了解RocketMQ。简单来说,就是一个分

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

【测试】输入正确用户名和密码,点击登录没有响应的可能性原因

目录 一、前端问题 1. 界面交互问题 2. 输入数据校验问题 二、网络问题 1. 网络连接中断 2. 代理设置问题 三、后端问题 1. 服务器故障 2. 数据库问题 3. 权限问题: 四、其他问题 1. 缓存问题 2. 第三方服务问题 3. 配置问题 一、前端问题 1. 界面交互问题 登录按钮的点击事件未正确绑定,导致点击后无法触发登录操作。 页面可能存在

黑神话,XSKY 星飞全闪单卷性能突破310万

当下,云计算仍然是企业主要的基础架构,随着关键业务的逐步虚拟化和云化,对于块存储的性能要求也日益提高。企业对于低延迟、高稳定性的存储解决方案的需求日益迫切。为了满足这些日益增长的 IO 密集型应用场景,众多云服务提供商正在不断推陈出新,推出具有更低时延和更高 IOPS 性能的云硬盘产品。 8 月 22 日 2024 DTCC 大会上(第十五届中国数据库技术大会),XSKY星辰天合正式公布了基于星

业务中14个需要进行A/B测试的时刻[信息图]

在本指南中,我们将全面了解有关 A/B测试 的所有内容。 我们将介绍不同类型的A/B测试,如何有效地规划和启动测试,如何评估测试是否成功,您应该关注哪些指标,多年来我们发现的常见错误等等。 什么是A/B测试? A/B测试(有时称为“分割测试”)是一种实验类型,其中您创建两种或多种内容变体——如登录页面、电子邮件或广告——并将它们显示给不同的受众群体,以查看哪一种效果最好。 本质上,A/B测

SWAP作物生长模型安装教程、数据制备、敏感性分析、气候变化影响、R模型敏感性分析与贝叶斯优化、Fortran源代码分析、气候数据降尺度与变化影响分析

查看原文>>>全流程SWAP农业模型数据制备、敏感性分析及气候变化影响实践技术应用 SWAP模型是由荷兰瓦赫宁根大学开发的先进农作物模型,它综合考虑了土壤-水分-大气以及植被间的相互作用;是一种描述作物生长过程的一种机理性作物生长模型。它不但运用Richard方程,使其能够精确的模拟土壤中水分的运动,而且耦合了WOFOST作物模型使作物的生长描述更为科学。 本文让更多的科研人员和农业工作者

MOLE 2.5 分析分子通道和孔隙

软件介绍 生物大分子通道和孔隙在生物学中发挥着重要作用,例如在分子识别和酶底物特异性方面。 我们介绍了一种名为 MOLE 2.5 的高级软件工具,该工具旨在分析分子通道和孔隙。 与其他可用软件工具的基准测试表明,MOLE 2.5 相比更快、更强大、功能更丰富。作为一项新功能,MOLE 2.5 可以估算已识别通道的物理化学性质。 软件下载 https://pan.quark.cn/s/57