Apache JMeter的高并发测试

之前搭建了集群，实现了负载均衡（尽管还没实现主备分发器自动切换，但是一个网站靠接收/响应请求就把服务器弄崩的应该不多吧），说的挺高大上，但是光说不练假把式，今天趁热打铁，对网站测试下高并发，有朋友推荐使用JMeter，那就来吧。

理了下思路，准备计划如下：

4台2核4G内存的服务器，一台用作主分发器，三台用作业务服务器。
一台6核16G内存服务器；一台8核32G内存服务器。
测试机器为windows系统，i5，6核8G内存（不同的压测机器也会对测试结果造成影响，也可在linux服务器上进行测试，因为只是为了测试负载均衡的效果，我就直接在本机进行测试了）；宽带为联通100M。
均不会配置缓存，安装nginx和mariadb。
云服务器带宽相同。地区均为东京云服务器。安装CentOS 8。
计划对3种服务器的<静态页面>进行高并发测试，并同步观察服务器内存情况。
目标参数：没有目标，我也不知道具体会是啥结果。

JMeter需要Java8+的支持，下载java，配置环境变量，一般来讲，会自动配置环境变量

安装JMeter，前往官网下载二进制程序解压即可。

命令控制台进入到JMeter安装目录下的bin目录，输入jmeter.bat，弹出如下画面，证明安装成功。

上面介绍不要用这个GUI界面来做负载测试，好吧，那待会就按照它的指导来吧。

For load testing, use CLI Mode (was NON GUI):
jmeter -n -t [jmx file] -l [results file] -e -o [Path to web report folder]

进入到该目录，控制台使用如下代码进行测试

jmeter -n -t D:/jmeter/bin/test/WebTest.jmx -l D:/res.log -e -o D:/Res

所有服务器均已安装nginx，为了保证测试的环境，只放行我的公网IP，也就是说，除了我的IP，谁也无法访问到网站。

安装django，配置mariadb，安装mysqlclient（折腾了一会），上传网站，确定能以公网IP:8000访问到首页。以下测试，每一次都保证了三次以上的测试，确保结果不会出现太大误差。三台服务器搭建的相同的django环境，端口均为8000，页面为首页，从左至右配置依次递增。Content-Length为444。

测试一：测试100用户/秒并发访问，持续10秒（可能由于机器性能问题，线程数量不一定能达到预期的要求，但是服务器之间比较的效果应该能看出来）。测试一的JMeter配置如下

2核4G测试前cpu基本值

开始测试大约3秒后，cpu急剧飙升至50左右，然后开始回落，关于%CPU超过100，说明是占用了多个核心

JMeter测试结果如下，均速417ms，0错误，99%的用户访问时间在922ms之内：

6核16G内存测试前情况：

测试后，上升至16左右开始回落

JMeter测试结果如下，网页响应速度比2核4G的表现还差

8核32G：

差不多上升到10%左右开始回落

JMeter测试结果如下

结论一：访问django静态页面的情况下，服务器内核和cpu的影响不大，并非所设想的配置越高访问越快；100用户并发访问，大概占用2核cpu。

测试二：300用户/秒并发访问，持续10秒。
2核4G测试后，cpu基本跑满

难怪django说自带的是轻量级web服务器，一定不能用于生产环境，这请求的首页，结果数据库崩了

jmeter报告如下，第3秒时，错误率就在15%以上，惨不忍睹

6核16G。cpu基本不会超过40%使用率

整体错误率并不比24低，机器带不动，没生成jmeter报告，命令行展示的数据如下

8核32G。测试最流畅，cpu占用基本在15%以下，平均响应时间只有2核4G的四分之一，错误率只占11.8%，配置高还是牛

结论二：不要用轻量级web服务器做网站。

测试三：配置uwsgi和nginx，并测试100用户/秒并发访问首页，持续10秒。

尽管以下的页面外在和之前的一样，但是内核已经完全不一样了，可以看到访问的是80端口，由于仅仅只是测试，所以就没有配置supervisor去守护uwsgi了。同步配置其它台服务器，其中唯一的区别可能就是nginx的worker_processes我是按照核数来增加的。

测试之前修改之前的HTTPSampler.port为80端口！

2核4G。下图一，左边为nginx日志，右边为内存，最高曾飙升到70%左右，均速为276.4ms，相较未配置nginx之前还是有明显提升。

6核16G。cpu占用最高在25%左右，均速212ms，巨大提升。

8核32G。均速225.91ms，看起来提升不大，cpu占用在10%左右。

结论三：做网站一定要使用正儿八经的web服务器，例如nginx，对于高并发的效果还是很显著的。

测试四：配置uwsgi和nginx，并测试300用户/秒并发访问首页，持续10秒。
2核4G。多次测试，错误率在44%-58%之间。均速降低了几十倍，只有675ms，nginx抗并发确实强。

6核16G。cpu基本在60%左右。均速在700ms，错误率相较之前大幅降低至14%。

8核32G。cpu基本在25左右，均速682，相较没有配置nginx之前缩短10倍！错误率也下降了一半至7%。

结论四：在网站每秒访问不超过200个用户时（测试可能存在一定误差，我按照100个用户差来计算），6核16G的性价比显然8核32G的更高。

测试五：为4台低配置服务器配置uwsgi和nginx，搭建集群，测试100用户/秒并发访问首页，持续10秒。
先为2-4-1配置分发器，达到访问2-4-1可以访问到三台业务服务器，为了看到效果，我将业务服务器的首页进行了更改。接下来只测试2核4G服务器搭建的集群，因为其它服务器的测试方法前面已经做过了。

2核4G集群。下图一为分发器2-4-1，cpu几乎没用，2，3，4为业务服务器，可以看到cpu上升。下图二，可以看到均速为245ms，相较6核16G内存，8核32G内存似乎没什么优势。

测试六：为4台低配置服务器配置uwsgi和nginx，搭建集群，测试300用户/秒并发访问首页，持续10秒。

2核4G集群。我只能说负载均衡太强了。均速746ms，但是0错误，相较6核16G的14%错误率，8核32G的7%错误率，这就太难得了。

测试七：集群、6核、8核，测试500用户/秒并发访问首页，持续10秒。

2核4G集群。均速1177ms，错误率在0-5%左右

6核16G。均速1047，错误率在30%左右

8核32G。错误率在10%左右

关于django网站做负载均衡，可能比普通网站稍微麻烦一点，在此进行记录，关于主分发器中nginx的配置

#nginx.conf中的配置
upstream demowebsite {
  #server unix:///srv/onlinedemo/onlinedemo.sock;
  server 45.76.51.26;
  server 45.76.196.14;
  server 167.179.79.209;
}
server {
    listen       80;
    server_name  202.182.107.126; # 自己的域名
    location / {
        #这个uwsgi_pass对应的参数一定要和upstream定义的一样
        #uwsgi_pass  demowebsite;
        proxy_pass http://demowebsite;
        #uwsgi_params文件地址
        include   /usr/local/nginx/conf/uwsgi_params  ;
}

其它业务服务器照正常流程配置uwsgi和nginx即可。但是需要在django的配置文件settings.py需要配置ALLOWED_HOSTS。其中demowebsite是分发器中的upstream名称（应该是）。

# 服务器公网IP以及
ALLOWED_HOSTS = ['45.76.51.26','demowebsite' ]

就我目前测试来讲，这个负载均衡其实做的并不规范，假设2-4-2这台业务服务器的uwsgi崩溃了，页面每三次会出现一个500错误（另外两台没问题的前提下），解决办法是为uwsgi配置守护进程，或者是uwsgi挂了，就把2-4-2这台服务器的nginx也kill掉，这样2-4-2这台服务器的自然会被踢出局，只剩下2-4-3和2-4-4两台业务服务器来处理请求，就不会出现下面这种页面了。

参考文章：

#jmeter官网
https://jmeter.apache.org/
# jdk
https://www.oracle.com/java/technologies/javase-jdk15-downloads.html
# mysqlclient安装
https://pypi.org/project/mysqlclient/
# Linux top命令里面%CPU和cpu(s)的差别
https://blog.csdn.net/q2519008/article/details/79985673

YOLO813

Apache JMeter的高并发测试