为什么要压测
这个问题问的其实挺没有必要的，做开发的同学应该都很清楚，压测的必要性，压力测试主要目的就是让我们在上线前能够了解到我们系统的承载能力，和当前、未来系统压力的提升情况，能够评估出当前系统的承载情况能不能满足当前和未来一段时间的正常运行。压力测试也让架构师和开发人员能够对自己负责的系统做到心中有数，当有大并发需求的活动或者其他突发事件导致的访问暴增，能够提前做好预估和准备应急预案。
压测难点
说了那么多，都是压测的必要性，那么既然要测那么重要，我们每次发版本都做一下压测不就好了，这么说的同学一定是没真正参与过压测的，参与过压测的同学都是谈压测色变，不管是测试人员还是开发人员都很害怕压测。大家为什么这么害怕压测，主要原因主要有下面这些压测的难点导致的：
1）压测环境难准备
在日常工作过程中，我们肯定遇到过压测环境难申请的问题，为什么难申请主要是因为压测一般要求环境和生产环境一致，那么就意味着压测机器资源的稀缺，没有哪家公司会长期准备所有系统的压测环境，毕竟成本太高，所以一般公司都是准备一些机器让所有系统共用压测环境，每次一个系统要做压测之前都要把上一个压测系统的数据和应用版本、中间件、数据库停掉或删掉，这是非常浪费时间的工作，所以很多公司现在在压测的环境准备都使用docker来准备环境，只需要定期更新docker image就可以，这就可以做到快速还原环境，需要用的时候直接把被测系统的docker image拉下来就行了，所以压测环境已经不再是我们的问题了。
2）压测数据难准备
在压测过程中还有个难点就是压测数据准备，如何能尽量真实的模拟生产的数据，最简单的就是录制一段时间生产的访问报文，然后在用压测环境进行正常回放和倍数回放。录制生产真实报文的工作，目前还没有遇到特别好的工具，大部分公司都是自己写个工具进行网络层面的嗅探，将嗅探到的生产报文再加工成Jmeter或者LoadRunner这些压测工具能够识别的压测脚本。这个工作其实只要搞通了一遍以后也没有那么复杂了。
3）压测工具使用复杂
压测工具曾几何时不管是测试人员还是开发人员都觉得很高大上，很难使用和学习，其实这个观念在10年前确实是这样的，但是随着越来越多的开源压测工具的兴起，那些复杂又笨重的商用压测工具渐渐被大家淡忘，现在有很多开源的服务端压测工具，使用起来还是很简单的，而且该有的功能基本都有了，前面废话了那么多，就是要说明压测已经不像以前那么复杂了，现在通过简单的环境配置和工具就可以快速的完成一次压力测试，环境准备这个我帮不了大家，今天文章重点就是介绍下开源压测工具的翘楚“Jmeter”的使用和结果分析，让大家爱上压测。
压测指标
压测结果指标基本概念：
- Samples:表示一共发出的请求数
- Average：平均响应时间，默认情况下是单个Request的平均响应时间（ms）
- Error%:测试出现的错误请求数量百分比。若出现错误就要看服务端的日志，配合开发查找定位原因
- Throughput:简称tps,吞吐量，默认情况下表示每秒处理的请求数，也就是指服务器处理能力，tps越高说明服务器处理能力越好
我们常用的压测指标其实并不多，主要就是用户并发量和tps，一般这两个指标是一起使用的，就是在用户这么大的并发量的前提下tps是每秒多少。这么说有点绕口，举个简单的例子，500个用户同时发起服务请求，服务端能够稳定正确处理的交易数。这里能够稳定正确处理的交易数就是我们常说的tps，也叫做服务处理吞吐量，例子中提到的500个用户同时发起服务请求，“同时发起”也很容易被误解，这里说的500用户同时发起请求是指的是500个用户同一秒钟发起的请求，并不是系统同时只能承载500个在线用户，这两个概念是完全不一样的，在制定指标的时候千万不要搞混，尤其是和业务人员沟通的时候一定要说清楚。一般来说我们会统计一段时间生产环境当前在线用户的会话数和接口当时被调用的次数，做个线性的乘数，通过这个乘数可以根据最后压测出的数据来评估系统大概能够承载的用户数。
使用Jmeter随时压测
下面我们就详细介绍下如何使用Jmeter来进行服务端接口压测，Jmeter安装起来非常方便，只需要去官网下载解压直接运行shell就可以了。
基本概念
在介绍如何使用Jmeter之前先介绍下Jmeter里的一些基本概念：
1）测试计划是使用 JMeter 进行测试的起点，它是其它 JMeter 测试元件的容器。
2）线程组：代表一定数量的并发用户，它可以用来模拟并发用户发送请求。实际的请求内容在Sampler中定义，它被线程组包含。可以在“测试计划->添加->线程组”来建立它，然后在线程组面板里有几个输入栏：线程数、Ramp-Up Period(in seconds)、循环次数，其中Ramp-Up Period(in seconds)表示在这时间内创建完所有的线程。如有8个线程，Ramp-Up = 200秒，那么线程的启动时间间隔为200/8=25秒，这样的好处是：一开始不会对服务器有太大的负载。线程组是为模拟并发负载而设计。
3）取样器（Sampler）：模拟各种请求。所有实际的测试任务都由取样器承担，存在很多种请求。如：HTTP 、ftp请求等等。
4）监听器：负责收集测试结果，同时也被告知了结果显示的方式。功能是对取样器的请求结果显示、统计一些数据（吞吐量、KB/S……）等。
5）逻辑控制器：允许自定义JMeter发送请求的行为逻辑，它与Sampler结合使用可以模拟复杂的请求序列。
6）断言：用于来判断请求响应的结果是否如用户所期望，是否正确。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。
7）定时器：负责定义请求（线程）之间的延迟间隔，模拟对服务器的连续请求。
8）配置元件维护Sampler需要的配置信息，并根据实际的需要会修改请求的内容。
9）前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置，后置处理器则常常用来处理响应的数据。
创建一个压力测试
- 创建线程组
通过右击测试计划->添加->Threads->线程组，进行线程组的创建。
线程组创建好了需要设置线程组，从设置界面其实可以知道主要的设置内容是线程数、Ramp-Up Period、循环次数、取样错误后执行的动作。
2)创建Http请求
从图上大家可以看到除了可以添加http请求还可以增加Java、JMS、FTP、JDBC等等，因为http请求用的最多所以这里我们就介绍创建http请求JSON接口的具体操作。
添加好Http请求，设置Http请求参数，这里设置http请求参数和我们使用一般调用一个http接口一样，主要需要设置几项内容：
协议：http还是https，这里我们设置http。
服务器名或IP地址：这里设置成自己项目的IP地址或域名。
端口：服务端口这里根据自己项目服务开放的端口来设置。
http请求方法（GET、POST、PUT等）
接口上下文路径：对应你要测试的接口上下文路径。
报文体：因为接口是JSON格式的，按照JSON格式送报文就可以了。
设置Http Header，在创建的Http请求上右击，选择添加->配置元件->HTTP信息头管理器。
因为是http JSON接口所以需要设置报文头里的Content-Type为application/json
压测结果分析
Jmeter对于压测结果可以设置多种监听器来查看结果，可以设置图形结果、结果树、断言结果、聚合报告等多种展示形式。下面分别给大家看下我比较常用的两种压测报告图形结果和聚合报告，这两个结果基本可以满足日常压测结果分析的需求了。
图形结果可以比较直观的查看到压测的结果数据，红色线表示偏离平均值的交易曲线，蓝色线表示平均响应时间，绿色线表示交易吞吐量，这里要注意下默认的吞吐量的时间单位是分钟。
这个是聚合报告，能够比较比较系统的所有被测接口的数据查看报告情况。
测试报告分析思路：
1）Error%:确认是否允许错误的发生或者错误率允许在多大的范围内；
2）Throughput：吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；
3）压测结束，登陆相应的web服务器查看CPU等性能指标，进行数据的分析;
4）最大的tps:不断的增加并发数，加到tps达到一定值开始出现下降，那么那个值就是最大的tps。
5）最大的并发数：最大的并发数和最大的tps是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。
6）压测过程出现性能瓶颈，若压力机任务管理器查看到的cpu、网络和cpu都正常，未达到90%以上，则可以说明服务器有问题，压力机没有问题。
7）影响性能考虑点包括：数据库、应用程序、中间件（tomact、Nginx）、网络和操作系统等方面。
总结
这篇文章先介绍了压测的重要性，又简单介绍了下我们常用的压测指标，最后重点介绍了下如何通过轻量级开源的Jmeter完成一次http接口的压测，并介绍了下测试报告分析的一个思路，轻量级的Jmeter可以让大家更加方便快速的开展压力测试，尤其对于压测条件不是很充分的小团队，使用这样的开源方案可以很方便的开展压测工作，让自己对系统的情况更加了解，最后希望大家都能够将Jmeter用起来。
微信扫一扫