电商网站的宕机案例分析

1.性能测试很多人认为最大的障碍就是测试脚本开发与测试结果分析,导致很多测试原忽略了测试规划与设计的重要性。

性能调优社区dynatrace在其博客中分享了客户案例,电商网站在假日客流峰值期间数次崩溃,经过SQL优化和调整负载均衡算法解决了相关问题,值得读者借鉴。

2.LoadRunner只是性能测试执行与分析的工具,应服从测试设计人员的意志,避免被工具牵着走测试。

按照博文的描述,该电子商务网站在圣诞节期间崩溃了七次,每次宕机的时间都超过5个小时。这种情况让企业损失了大量的收入和名誉。

3.压力测试=指标测试,以不断增加压力来找到系统的极限。

我们的一个客户就曾经遭遇到这种情况,我们在此分享下他们的经历。宕机的原因有很多,不过我们这里只强调比较突出的一点,即负载均衡器在采用Round-Robin(轮询)算法时比Least-Busy
(最休闲)算法更容易导致应用服务器因堆内存耗尽而崩溃。

4.开发阶段的性能测试:一边开发一边性能测试,需要一个反复迭代的过程。通过开发阶段的性能测试可以发现一些核心算法的问题

在分析性能问题之前,先看一看该网站的拓扑结构。该电子商务网站部署在6个Tomcat应用服务器上,前面是3个Apache
Web服务器。

5.负载发生器(Load Generator)也叫压力产生器。

面临的问题是,在负载高峰时刻,每个Tomcat实例处理的响应时间开始增长,等待队列中的请求数目增多。一段时间之后,这些Tomcat实例由于
OutOfMemory异常而崩溃,随后其他实例也因为承受不住由此增加的负载而宕机。

6.基于浏览器但使用HTTPS安全协议的录制,建议使用URL-based
script方式。(包含javaScript的也是)

即使在采用平均分布负载的算法(Round
Robin)下,有些Tomcat应用服务器也会出现响应时间的跳跃。一旦服务器开始拒绝客户连接,我们会发现一些连锁反应。数据库层出现大量的异常,同时应用层之间会抛出异常,Web服务器会返回给浏览器HTTP
500的错误。

比如,在实际的分析过程中,我们发现某一个Tomcat实例在30分钟内对43000个页面返回了HTTP
500错误。

7.创建URL(WEB_url)表单提交(web_submit_from)链接(web_link)图像(web_image)

原因分析:来自数据库层(JDBC)的异常是分析该问题的关键入口。仔细查看这些异常会发现连接池已经耗尽了,从而导致应用的各个部分出现问题。由于连接池的原因,每一个请求都需要平均等待3.8秒来从池里获取连接。

8.性能测试以后将是主流。
9.性能测试不是给你一个指标,你按照指标记录下结果那么简单。

不光是连接池大小的设置问题,而且不少低效的数据库语句在执行应用的一些业务逻辑事务时花费了太长时间。这导致应用服务器维护这个连接的时间也较长。如果把负载均衡器设为Round
Robin算法,应用服务器会继续获得其他的请求。最终,由于客户请求的随机性,某个应用服务器收到了不少执行低效数据库处理的请求。一旦连接池耗尽,应用服务器就开始抛出异常,并最终导致JVM崩溃。一旦第一个应用服务器出现问题,用不了多久其他服务器也挂掉了。

10.内存溢出导致响应时间、tps异常;查表导致数据库cpu异常可能是存储过程需要调优。

解决办法:优化应用程序和负载均衡器

11.虚拟用户数、每秒点击数、每秒事物数、响应时间

首先要分析执行最慢的数据库语句,并做性能优化,比如增加索引等。同时也优化了连接池大小来满足高峰时刻的需求。然后,企业把负载均衡器的算法从Round-Robin改为了Least-Busy,在生产环境中这个配置经常被人遗忘。自从对应用程序和负载均衡器做了修改之后,网站再也没有崩溃。

12.性能分析:1)测试过程中环境异常,比如cup过高,网络不稳定,系统参数不正确等,这样的结果无效无需分析;2)逐步施压,
否则导致服务器无法接到全部的压力请求,导致测试失败。3)性能测试直接暴露的问题:事务响应时间过长,系统支持最大并发用
户量过低,系统应用服务器cpu利用率过高或内存不足等。

该企业之前做过负载测试,但是存在两个问题:

13.服务器内存不够可能会引起较大的磁盘I/O,进而导致cpu利用率居高不下,其根本原因可能是程序内部内存泄漏,而不是内存瓶
颈。

  1. 没有使用预期的峰值负载长时间测试。
  2. 没有完全模拟用户行为,测试脚本太少、太简单,缺少了用户的高交互性访问场景。

14.导致数据库异常停止服务的原因:1)程序算法的缺陷2)数据库配置不正确;算法上的缺陷导致cpu资源过度消耗,数据库配置上
的错误导致数据库系统运行的异常。

由此等到的经验教训:在生产环境的低访问量时段(凌晨2点到6点)执行负载测试,这样可以虽然有小的交易风险,但是可以避免大的经济损失。高峰时间长为10小时,不要测试太短时间。

15.数据库调优 >
Oracle的专有服务模式和共享服务模式:专有服务连接采用一对一的连接方式,能很快的响应用户的请求。但由于
用户的连接数过多,为每一个用户分配连接资源,对硬件的要求比较大。共享服务模式,即一个服务器响应多个用户连接。只要用户
请求执行完,就会马上断开连接,分配器会把空闲的服务器进程分配给其他排队的用户进程。

关于负载均衡的基本算法,主要有以下几种(参考F5产品):

16.待续中…. 关注更新@

  • 随机:负载均衡方法随机的把负载分配到各个可用的服务器上,通过随机数生成算法选取一个服务器,然后把连接发送给它。虽然许多均衡产品都支持该算法,但是它的有效性一直受到质疑,除非把服务器的可运行时间看的很重。
  • 轮询:轮询算法按顺序把每个新的连接请求分配给下一个服务器,最终把所有请求平分给所有的服务器。轮询算法在大多数情况下都工作的不错,但是如果负载均衡的设备在处理速度、连接速度和内存等方面不是完全均等,那么效果会更好。
  • 加权轮询:该算法中,每个机器接受的连接数量是按权重比例分配的。这是对普通轮询算法的改进,比如你可以设定:第三台机器的处理能力是第一台机器的两倍,那么负载均衡器会把两倍的连接数量分配给第3台机器。
  • 动态轮询:类似于加权轮询,但是,权重值基于对各个服务器的持续监控,并且不断更新。这是一个动态负载均衡算法,基于服务器的实时性能分析分配连接,比如每个节点的当前连接数或者节点的最快响应时间等。
  • 最快算法:最快算法基于所有服务器中的最快响应时间分配连接。该算法在服务器跨不同网络的环境中特别有用。
  • 最少连接:系统把新连接分配给当前连接数目最少的服务器。该算法在各个服务器运算能力基本相似的环境中非常有效。
  • 观察算法:该算法同时利用最小连接算法和最快算法来实施负载均衡。服务器根据当前的连接数和响应时间得到一个分数,分数较高代表性能较好,会得到更多的连接。
  • 预判算法:该算法使用观察算法来计算分数,但是预判算法会分析分数的变化趋势来判断某台服务器的性能正在改善还是降低。具有改善趋势的服务器会得到更多的连接。该算法适用于大多数环境。

16.系统点击率下降通常表明服务器的响应速度在变慢。                                                                   

17.HTTP状态码 200正常 202已接受请求,但处理尚未完成 400不正确的请求
401未经授权的客户试图访问受密码保护的页面 402需要付费
403资源不可用,服务器理解客户请求,但拒绝处理;通常是由与服务器上的文件或目录权限设置导致的
404不说了
405请求方法(GET/POST/HEAD/DELETE/PUT/TRACE)对指定的资源不适用
414URI太长 415不支持的媒体类型 500服务器内部错误,不能够完成请求
501服务器不支持现请求所需要的功能
504网关超时,表示不能及时从远程服务器获得应答
505服务器不支持请求中指明的HTTP版本

18.测试计划:1)环境搭建拉通 2)功能测试(测试用例设计、功能测试执行)
3)性能测试(测试用例设计、测试数据预置、测试脚本开发录制、测试用例执行、测试结果分析)
4)报告编写(结果分析、测试报告)

19.性能测试种类:核心业务场景测试/组合业务场景测试/强度测试/大数据量测试

20.性能测试范围:重点测试版块/非重点测试版块

21.性能测试目标:通过性能测试实现对服务器的综合性能评估,尽可能真实的反应系统的性能情况,为调整与优化系统提供参考。

22..待续中…. 关注更新@

22.controller 关联
:web_reg_save_param(”WangYong”,”LB=<tale>”,”RB=</table>”,”Ord=All”,”search=body”,”RelFrameId=All”,”IgnoreRedirections=Yes”,LAST);Ord默认为1,如果搜索到的字符为多个用all。search指定搜索范围,header、body、header
and body .

  1. cat  prmt_interface.log | grep “Promotion:10.40.16.231|DNA” | awk
    -F ‘|’ ‘{print $1}’ |sort | uniq -c