大型网站压力测试及优化方案

目录

 
 
木桶理论应用在系统优化中
 
木桶理论又称短板理论,其核心思想是一只木桶盛水多少,并不取决于最高的木板,而取决于最短的那块木板。
木桶原理应用在系统分析中,即系统的最终性能取决于系统中性能表现最差的组件,为了提高系统总体性能,对系统中表现最差的组件进行优化能够获得最好的效果。
 
 
在网站系统中,用户的访问请求到达服务器,而后服务器返回数据并展现给用户,这个过程要通过不少处理,每个过程的低效都会影响系统总体表现出来的性能。
 
按照木桶理论,若是一台服务器性能很是强大,拥有充足的内存资源和CPU资源,可是磁盘I/O性能不足,那么系统的整体性能是取决于当前最慢的磁盘I/O速度,而不是当前最优越的CPU或者内存,此时,磁盘I/O就是系统的性能瓶颈。
 
典型的好比使用Redis进行存储的系统,因为Redis自己性能很是优秀,一般状况下存储并不会制约系统的性能,在海量请求的状况下,Redis的吞吐量会很是大,这时候制约系统的性能瓶颈就变成网络带宽。
 
 

压力测试如何实施

性能测试在大型网站系统的设计和开发中很是重要,一般会和容量预估等工做结合在一块儿,穿插在系统开发的不一样方案。
性能测试能够帮助咱们及时发现系统的性能短板,评估系统的能力,在这个基础在上再进行针对性的性能优化。
同时,压力测试还能够帮助咱们验证系统的稳定性和可靠性。
 
一个完整的性能测试方案一般包括如下几个方面: 

1.压力测试及生成性能报告

压力测试一个重点是如何产生压力,一般能够经过本身编写脚本模拟请求,或者使用成熟的压测工具进行。
压力测试很重要的一点是如何使得模拟压测的数据尽可能真实,越接近真实用户越好。

2.根据性能报告定位系统瓶颈,进行针对性优化,测试和优化的工做能够和平常开发并行

压力测试完成之后,咱们会拿到一个压测报告,这个报告一般会告诉咱们系统的QPS、TPS、响应时延等数据,
这些数据可让咱们对服务器的性能有个总体的了解,发现存在的问题,可是不能帮助咱们定位问题。
 
这个时候咱们能够从系统的各个组件入手,关注系统的CPU、内存、IO、网络,对比这些环节对总体性能的影响,肯定性能问题是系统哪一部分形成的,而后针对性的在系统中逐个优化。

3.估算容量承载能力,合理规划系统资源

进行压力测试的一个重要目的是让现有的服务器资源发挥最大的价值,
通过前期的测试和分析,这时候咱们对系统总体的性能有了一个认识,对服务器的承载能力有了预估,
这个时候咱们就能够结合业务规模配置服务器数量,CDN资源等,让最少的资源产生最大的价值。

 

经常使用压力测试工具选型

压力测试很关键的一点是如何产生压力,选择哪款测试工具很重要,大的互联网公司如百度/腾讯等,都有专门的测试开发团队,开发公司内部应用的测试工具,以便更好的适应公司的业务,做为SAAS服务的重要部分,几个云服务提供商也纷纷开放了压测及性能监控服务。
大多数公司仍是会选择本身完成测试工做,这里关注一下经常使用的压力测试工具。 

1.几款流行的压力测试工具 

(1)JMeter
Apache JMeter是Apache组织开发的基于Java的压力测试工具,用于对软件作压力测试,它最初被设计用于Web应用测试但后来扩展到其余测试领域。 它能够用于测试静态和动态资源例如静态文件、Java小服务程序、CGI脚本、Java 对象、数据库, FTP服务器, 等等。
 
JMeter 能够用于对服务器、网络或对象模拟巨大的负载,来在不一样压力类别下测试它们的强度和分析总体性能。
另外,JMeter可以对应用程序作功能回归测试,经过建立带有断言的脚原本验证你的程序是否返回了指望的结果。
为了最大限度的灵活性,JMeter容许使用正则表达式建立断言。
 
(2)LoadRunner
LoadRunner是惠普旗下一款自动负载测试工具,它能预测系统行为,优化性能。LoadRunner强调的是整个企业的系统,它经过模拟实际用户的操做行为和实行实时性能监测,来帮助更快的确认和查找问题。此外,LoadRunner 能支持最宽范的协议和技术,量身定作地提供解决方案。
 
(3)其余测试工具
  • Siege是一款开源的压力测试工具,能够根据配置对一个WEB站点进行多用户的并发访问,
记录每一个用户全部请求过程的相应时间,并在必定数量的并发访问下重复进行。
  • TCPCopy是一种请求复制(全部基于tcp的packets)工具,能够把在线请求导入到测试系统中去。
TCPCopy的特色是能够拷贝线上真实流量,模拟用户数据。
 

2.性能测试工具的横向对比

这里对比主流的 JMeter和LoadRunner,通常来讲,除了自研测试工具的公司,互联网公司使用JMeter做为测试工具的较多。
  JMeter LoadRunner
开发语言 纯Java开发 使用C语言开发
支持应用 对Java为主的系统支持较好 支持比较全面
是否收费 开源免费 商业软件
学习成本 应用简单,上手快,Java自定义测试计划 功能复杂,学习成本高
协议支持 支持常见的HTTP/FTP/SMP等 支持较全面
自定义测试 支持使用Java编写Sample 使用完善的组件进行定制化测试
组件功能 Thread Group, Samplers, Listeners, Pre & Post processors 一套完整的测试组件,好比VU Generator, Controller, Analyzer, Load generator, Load calculator 和protocol advisor.
 
 

如何监控系统资源,定位性能瓶颈

压力测试能够暴露系统性能问题,如高并发下访问缓慢,服务宕机等,可是经过压测不能具体到哪里存在瓶颈,必需要在压测同时配合适当的资源监控,帮助咱们定位问题。正则表达式

1.配置合理的资源监控方案

(1)使用nmon监控系统性能
 
nmon是Linux上普遍使用的监控与分析工具,相对于其它一些系统资源监控工具来讲,nmon所记录的信息是比较全面的,它能在系统运行过程当中实时地捕捉系统资源的使用状况,而且能输出结果到文件中,而后经过nmon_analyzer工具产生数据文件与图形化结果。
 
nmon所记录的数据包含如下一些方面:
  ● cpu占用率
  ● 内存使用状况
  ● 磁盘I/O速度、传输和读写比率
  ● 文件系统的使用率
  ● 网络I/O速度、传输和读写比率、错误统计率与传输包的大小
  ● 消耗资源最多的进程
  ● 计算机详细信息和资源
  ● 页面空间和页面I/O速度
  ● 用户自定义的磁盘组
  ● 网络文件系统
 
(2)使用rpc.rstatd监控系统性能
 
rpc.rstatd一般配合LoadRunner一块儿使用,注意与系统服务rpc.statd进行区分。
rstatd后台程序能够从系统核心中获取系统性能统计的相关信息,将结果返回给调用程序。
进行压力测试时,LoadRunner客户端经过给服务器上的 rstatd 后台程序发送请求,来收集应用或数据库服务器的性能数据。
 
(3)针对不一样的服务合理配置资源监控方案
以Java服务为例,在压测同时能够对JVM虚拟机进行性能监控,这方面经常使用的有Jvisualvm、jps、jstack等。
下面是Jvisualvm的应用界面,能够监控本地和远程的JVM实例运行状态。
 

针对测试报告进行针对性优化

在压力测试发现问题之后,就要进行有针对性的优化。对于不一样的系统,这个过程的策略并非肯定的,可是大概能够划分为如下几个步骤: 

1.定位性能瓶颈,找出系统存在的问题 

不一样系统的特色不一样,在性能瓶颈上也有不一样的表现,通常来讲,下面的几个方面一般存在比较大的优化空间:
 
(1)磁盘I/O及文件操做
因为磁盘I/O读写的速度要比内存慢不少,程序在运行过程当中,若是须要等待磁盘I/O完成,那么低效的I/O操做会拖累整个系统。
 
(2)网络操做
对网络数据进行读写的状况与磁盘I/O相似。因为网络环境的不肯定性,尤为是对互联网上数据的读写,网络操做的速度可能比本地磁盘I/O更慢。
 
(3)CPU
对计算资源要求较高的应用,因为其长时间、不间断地大量占用CPU资源,那么对CPU的争夺将致使性能问题。如科学计算、3D渲染等对CPU需求旺盛的应用。
 
(4)高并发下的上下文切换及锁竞争等
高并发程序若是没有作好优化,存在大量的锁竞争,激烈得锁竞争将会明显增长线程上下文切换的开销,对性能形成极大的影响
 
(5)数据库
大部分应用程序都离不开数据库,而海量数据的读写操做多是至关费时的。而应用程序可能须要等待数据库操做完成或者返回请求的结果集,那么缓慢的同步操做将成为系统瓶颈。

2.肯定调整目标,提出解决方案

找到系统的性能问题之后,须要做出对应的解决方案。
 
典型的影响性能的问题,好比:
(1)系统对高并发的场景响应不足,如数据库链接池太低,服务器链接数超过上限,数据库锁控制考虑不足等
(2)内存泄露,如在长时间运行下,内存没有正常释放,发生宕机等
(3)数据库优化不足,业务日益增加,关联表众多,SQL不够优化等
 
定位到上述问题,接下来就是提出合理的调整目标,
好比服务器资源有限,能够经过配置更多的机器,服务上云等进行优化;
若是对高并发支持很差,就能够在代码层面优化,提升并发支持;
数据库性能问题,如慢查询等问题,就能够进行 SQL语句优化等。

3.实施解决方案,进行迭代开发

上一步的分析给出了一个初步的性能优化方案,接下来就是针对方案中提到的内容进行针对性的改进。
这个过程能够应用敏捷的思想进行迭代,在开发完成后,为了对比优化结果,能够对调优后的系统进行小范围测试。

4.进行基准测试并分析调优结果

数听说明一切,性能优化的结果不能简单的经过 “感受系统变快了”来衡量,最好是经过对比优化先后的测试结果,用图表的方式直观的把优化结果展现出来。基准测试是指经过设计科学的测试工具和方式方法,实现对一类测试对象的某项性能指标进行定量的和可对比的测试。对比测试结果,结合容量评估等工做,可让系统发挥最大的效用。
 
一个阶段的优化工做完成之后,最好是总结反思一下,好比本次优化是否达到了目标?系统的总体性能是否获得了改善?用户体验是否获得了提高?以及如何在接下来的开发工做中作的更好。

 

使用JMeter进行压力测试实践

JMeter是目前流行的测试工具,这里简单的介绍一下相关的应用。

1.JMeter安装与使用

Linux下可直接下载安装,MAC系统进入http://jmeter.apache.org/download_jmeter.cgi下载apache-jmeter-3.1.tgz。
下载完毕后解压,获得安装包,进入到进入解压目录/bin/,单击jmeter图案,便可启动JMeter。 

2.基本组件简介

应用JMeter须要熟悉一些基本的概念,这是编辑测试计划的界面:
 
 
(1)Threads 线程组
这个组件主要用来控制Jmeter并发时产生线程的数量,在它的下一级菜单下只有一个组件(线程组),能够这么理解每一个线程就是一个虚拟的用户。全部的其余类型组件必须是(线程组)节点的子节点。
 
(2)ConfigElement 配置单元
和Sample组件一块儿工做,主要用来配置Sample如何来发起请求访问服务器,这个东西的主要特色是能够把一些Sample的共同配置放在一个元素里面方便管理,配置单元是有做用域的。做用域和树的那个关系同样越是上级节点的做用域越大,越是接近叶子节点的
做用域就越小,能够复写上级做用域的配置。
 
(3)Timer 定时器
这个主要是用来调节(线程组),控制线程每次运行测试逻辑(好比说:发出请求)的时间间隔。固然这个下面还有不少类型的定时器,他们主要功能就是调节时间间隔,但个个组件之间的策略有很大不一样。
 
(4)Pre Processors 前置处理器 / Post Processors 后置处理器
相似一个HOOK,在测试执行以前和执行以后执行一些脚本的逻辑。该组件我尚未具体使用过,但大体功能就是这样,非重点组件。
 
(5)Assert 断言
是指对于Sample完成了请求发送以后,判断一下返回的结果是否知足指望。
 
(6)Listener 监听器
这个组件不一样于平时在Web编程的那种监听器,他是伴随着Jemeter测试的运行而从中抓取运行期间的数据的一个组件,常用的是聚合报告组件,从里面能够统计到测试的TPS,响应时间等关键测试数据。

3.进行第一个测试

(1)设置线程组参数
首先在TestPlan下面添加一个ThreadGroup组件,设置线程组组件各项参数。
 
 
线程数:最大测试时使用的线程数。
Ramp-Up Period : Jmeter达到指定最大线程数的时间。
循环次数 : 若是是Forever,线程组中的线程将不间断的连续测试系统,固然也能够设置每一个线程测试的次数,当完成了规定次数后,该线程将自动退出线程组。
 
(2)添加Sampler信息
保存线程组后,接着在线程组下面添加Sample组件,咱们添加一个HTTP Request组件,
设置属性以下图:
 
Sampler表示客户端发送某种格式或者规范的请求到服务端,因此有各类各样的Sampler,如FTP/JDBC等。
这里我添加了一个针对百度百科首页的访问请求,端口为80,使用http协议。
 
(3)添加聚合报告的监听器组件
添加一个Aggregate Report的listener的监听器组件。
Aggregate Report 是 JMeter 经常使用的一个 Listener,中文被翻译为“聚合报告”。
 
(4)启动运行
点击RUN运行测试便可。而后能够看到本次测试的Aggregate Report。
 

4.Jmeter中的几个重要测试指标释义

能够看到,上面的聚合报告中有不少维度的信息,简单介绍几个比较重要的指标。
 
Label 每一个 JMeter 的 element(例如 HTTP Request)都有一个 Name 属性,这里显示的就是 Name 属性的值
#Samples 表示你此次测试中一共发出了多少个请求,若是模拟10个用户,每一个用户迭代10次,那么这里显示100
Average 平均响应时间——默认状况下是单个 Request 的平均响应时间,当使用了 Transaction Controller 时,也能够以Transaction 为单位显示平均响应时间
Median 中位数,也就是 50% 用户的响应时间
90% Line 90% 用户的响应时间,其余的几个能够类推
Min 最小响应时间
Max 最大响应时间
Error% 本次测试中出现错误的请求的数量/请求的总数
Throughput 吞吐量——默认状况下表示每秒完成的请求数(Request per Second)
Received / Sent KB/Sec 每秒从服务器端接收到/发送的数据量
相关文章
相关标签/搜索