· 木桶理论应用在系统优化中
· 压力测试如何实施
· 常用压力测试工具选型
· 如何监控系统资源，定位性能瓶颈
· 针对测试报告进行针对性优化
· 使用JMeter进行压力测试实践
木桶理论应用在系统优化中
木桶理论又称短板理论，其核心思想是一只木桶盛水多少，并不取决于最高的木板，而取决于最短的那块木板。
木桶原理应用在系统分析中，即系统的最终性能取决于系统中性能表现最差的组件，为了提升系统整体性能，对系统中表现最差的组件进行优化可以得到最好的效果。
在网站系统中，用户的访问请求到达服务器，然后服务器返回数据并展示给用户，这个过程要经过很多处理，每一个过程的低效都会影响系统整体表现出来的性能。
按照木桶理论，如果一台服务器性能非常强大，拥有充足的内存资源和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 | 每秒从服务器端接收到／发送的数据量 |
