实战：利用Jmeter在生产环境上进行压测

我的上一篇文章：Mac上Python Web的部署：Nginx+Gunicorn+Flask+Supervisor，解释了生产环境的部署
那么既然用上了嗷嗷好用的web服务器，性能比flask等框架自带的强了许多，要不来压测一把？下面就来看看如何在生产环境进行压测。
工具我们选用jmeter，如何使用jmeter写压测脚本，不在本文赘述。因此我们认为你已经准备好了一份可以运行的脚本。

一、施压机的准备

首先准备脚本的时候，可以在自己工作电脑上写和调试。但是一般不建议直接用自己的工作电脑当做施压机，对生产环境的服务器进行压测。
因为我们本地的机器到生产环境上，可能存在网络等各位问题，不一定能反映出真实的性能。因此，我们需要在生产环境上准备一台机器，作为施压机。
如果是在公司里面，一般让运维去搞就好了，告诉他被压机器的网段，以及机器性能需求，他会给你准备好。然后安装上jmeter。

举个例子，我曾经做过实验，对比本机和生产环境作为施压机，运行同样的脚本，得到的结果相差近10倍。因此想要得到准确的结果，必须使用生产环境的机器来施压。

二、压测脚本

jmeter建议只用GUI工具用来调试脚本，实际运行脚本要在命令行上运行。
因为jmeter用Java开发的，图形化本身会占用较多资源，导致压测机本身能产生的并发少，命令行会节省图形界面的资源开销。
如果是生产环境上的施压机，一般是纯命令行的linux，自然也只能用命令行来操作。

所以你需要学会上传压测脚本到施压机，以及如何使用命令行启动jmeter执行压测。压测完了之后，还需要把生成的报告等文件再下载到本机进行整理。

上传、下载
我们通常使用rz/sz命令，和Linux服务器进行文件上传下载。
如果你用的终端不支持这个命令，请搜索并安装。比如我的Mac就不支持。
通过命令行进行压测
我的压测脚本已经上传到了/Users/cynthia/test20190419.jmx，直接运行下面的命令

jmeter -n -t /Users/cynthia/test20190419.jmx  -l /Users/cynthia/test20190419.jtl -e -o /Users/cynthia/test20190419

这样会，生成jtl文件，和一份html格式的报告。
当然你也可以只生成jtl文件，稍后再通过下面的命令生成报告：

jmeter -g test20190419.jtl -e -o /Users/cynthia/test20190419

打包上传、解压
压测一般都会做好几组，也会生成很多文件，所以打包之后再传输到本地比较方便。
使用下面的命令，就可以把/Users/cynthia/文件夹里的所有文件，压缩成一个包，并进行传输。

tar -czf cynthia20190419.tar.gz /Users/cynthia/
sz cynthia20190419.tar.gz

传输到本地之后，使用下面的命令解压：

tar -xzf cynthia20190419.tar.gz

三、关注服务器的性能指标

jmeter可以通过插件的方式来监控服务器的各项指标。不过一般公司都会有自己的监控系统，比如zabbix等，功能更为强大。本文我们就用zabbix来进行监控。

下面来说说如何设置zabbix的监控屏幕：
登录zabbix，Monitoring-->Screens-->Create Screen，输入行列新建一个面板，然后点进去，Edit screen，增加你想要监控的机器相关指标，即可。
这里可以监控CPU load,CPU utilization,Disk space usage,Disk vda IOPS,Disk vda IO speed,Disk vda IO util,Disk vda IO wait,Free memory space,Memory usage,Network traffic,Operations read and write,Read and Write speed,Sectors read and write,Swap usage,Tcp State等等各项指标。

设置好监控屏幕之后，只需要在压测过程中查看该页面，就可以图形化的显示出你所关注的服务器的性能指标。

小提示：由于可以监控的指标众多，所以建议在压测开始之前，根据自己的具体情况，确定好关注的指标，添加并监控即可。否则添加了太多，看起来也挺累的。

另外，如果还有其他人也很关注这次的压测情况，请务必提前和他沟通，问清楚他关注的指标，免得测完了才发现只添加了自己关注的指标……

四、数据整理

对于jmeter直接生成的报告，要检查并结合实际情况，进行整理。不要看到错误率很高就以为一定是真正的出错，可能的原因有很多。

比如：
服务器对连接数、高并发等做了限制，因此用户数加上去之后会出现大量错误。此时可以在服务器端修改连接数限制，或者针对施压机增加白名单。
jmeter对于error的默认判断标准，并不符合实际某些场景，此时要么在脚本中增加一些后置处理，要么根据压测生成的文件，自行手动处理。

五、服务器下线

由于是生产环境机器，很多情况下有费用产生，而压测一般只是短期需求，所以压测结束之后，把相关数据备份完毕，就可以进行服务器下线操作，节省费用。土豪随意。