Nginx网络架构实战学习笔记(五):大访问量优化整体思路、ab压力测试及nginx性能统计模块、nginx单机1w并发优化

版权声明:本文为作者原创,转载请注明出处,联系qq:32248827 https://blog.csdn.net/dataiyangu/article/details/88963159

大访问量优化整体思路

高性能的服务器的架设

对于高性能网站 ,请求量大,如何支撑?
1方面,要减少请求
对于开发人员----合并css, 背景图片, 减少mysql查询等.

打开网易新闻,发现首页的css是直接写在html里面的

2: 对于运维 nginx的expires ,利用浏览器缓存等,减少查询.

3: 利用cdn来响应请求

4: 最终剩下的,不可避免的请求----服务器集群+负载均衡来支撑.

所以,来到第4步后,就不要再考虑减少请求这个方向了.
而是思考如何更好的响应高并发请求.

大的认识-------既然响应是不可避免的,我们要做的是把工作内容”平均”分给每台服务器.
最理想的状态 每台服务器的性能都被充分利用.

ab压力测试及nginx性能统计模块

服务器介绍:

服务器IP:
A 192.168.1.201
B 192.168.1.202
C 203
D204

Root: zixue.it

1台 A
RAM: 2G
HD: 500G

3台 B, C, D
RAM: 8G
Hd : 200G
在这里插入图片描述
步骤:
1:A号服务器
1.1安装 mysql
1.2并导入数据.
注意:先把表中的索引去掉,加快导入速度

2: C号服务器:
2.1: 编译PHP
注意: enbale-fpm , with-mysql=mysqlnd (编译成独立fpm进程,支持mysql,)
2.2: 下载第3方的memcached扩展 编译进来

3: D号服:
3.1 编译 memcached

4: B号服:
编译nginx ,并配置
Cd /app/pcre-8.12
./configure
Make && make install

Cd nginx-1.2.7
./configure --prefix=/usr/local/nginx --add-module=/app/ngx_http_consistent_hash-master
注:红线部分是nginx的第3方模块,需要自己下载.

安装统计模块,便于观察nginx的状态
./configure --prefix=/usr/local/nginx/ --add-module=/app/ngx_http_consistent_hash-master --with-http_stub_status_module

Php 安装配置
1 tar -xzvf /path/’
2 cd /path/
3 .configure --prefix=/usr/local/php –

ab压力测试及nginx性能统计模块

ab压力测试

希望B(nginx),在没有php和mysql的情况下能够达到1000并发。

重新编译nginx

rm -rf nginx
pkill -9 nginx 
cd nginx-1.2.7
./configure --prefix=/usr/local/nginx/ --add-moudle=/app/ngx_http_consistent_hash-master
//压力测试需要用到apache的小工具 ab
make && make install
cd /usr/local/httpd/
ls bin/
//发现下面有一个 ab

在192.168.1.202安装nginx
访问http://192.168.1.202 ,查看是否安装成功。

通过ab工具进行并发测试

//-c 1000个并发,-n 测试50000次
./bin/ab -c 1000 -n 50000 http://192.168.1.202/index.html

在这里插入图片描述
server software 用的是nginx
concurrency level 1000 并发1000
complete requests 50000 请求了5000次
failed requests 3721 失败了3721次
在这里插入图片描述

80%以内 用了100ms以内
90%到95%是1000ms
95%到98%是16000ms
99%到100%,即1%超过了3000m

//-c 2000个并发,-n 测试80000次
./bin/ab -c 2000 -n 80000 http://192.168.1.202/index.html

这个时候报错了,机器虽然不好,但是这样的并发还是能接受的
在这里插入图片描述
所谓高并发,需要先由硬件需求

上面的意思是打开的文件太多了
在linux认为,一切的操作,无论是硬盘软盘、打印机、鼠标等都是文件
每次来一个请求都要有一个socket连接,socket连接在linux看来就是把网卡打开了一次,就是打开了一次文件,1000个并发,打开了一千次,打开的太多了。

注意这里是通过ab这个客户端压力别人,这里的ab客户端都已经撑不住了,同理服务器也会出现这个错误,所以服务器硬件条件够强

修改限制

//linux默认只让打开1024个描述符
ulimit -n
1024
//注意这里的20000,一重启服务器马上就失效了
ulimit -n 20000

再进行压力测试

//-c 2000个并发,-n 测试80000次
./bin/ab -c 2000 -n 80000 http://192.168.1.202/index.html

在这里插入图片描述
20%都是在7m以上
在这里插入图片描述
一共请求了80000 失败了70000+

nginx性能统计模块

为了更清楚的看到每时每刻有多少并发多少等待
添加新的模块

安装统计模块,便于观察nginx的状态
./configure --prefix=/usr/local/nginx/ --add-module=/app/ngx_http_consistent_hash-master --with-http_stub_status_module

cd /app/nginx-1.2.7
./configure --help|grep status
make clean
./configure --prefix=/usr/local/nginx/ --add-moudle=/app/ngx_http_consistent_hahs-master --with-http_stub_status_moudle
make && make install

配置

cd /usr/local/nginx/
vi conf/nginx.conf
	location /status{
		//打开状态查看
		stub_status on;
		//关闭日志
		access_log off;
		//只允许 192.168.1.100查看,其他的一律拒绝
		allow 192.168.1.100;
		deny all;
	}
./sbin/nginx -s reload
//如果还没有启动nginx
./sbiin/nginx

访问:http://192.168.1.100/status
输出如下:

//当前活着的连接
Active connections:1
//已经完成的连接
server accepts handled requests
111
//当前等待的请求
Reading:0 Writing:1 Waiting:0

在这里插入图片描述

再通过ab压力测试

//-c 2000个并发,-n 测试100000次
./bin/ab -c 2000 -n 100000 http://192.168.1.202/index.html

然后不算的刷新http://192.168.1.100/status
发现最多只有700个并发,最后通过ab的输出,发现100000个请求有90000失败了

nginx单机1w并发优化

优化思路:
nginx响应请求
1:建立socket连接
2: 打开文件,并沿socket返回.
其实高并发,无非就是上面两个条件

排查问题,也要注意观察这两点,
主要从系统的dmesg ,和nginx的error.log来观察

tail logs/error.log
dmesg|tail

在这里插入图片描述
80 端口特别快是不是遭受到socket攻击了?所以“sending cookies”,每次请求带了一个cookie过去,防止别人攻击。

正式开始

ulimit -n
1024
//注意这个参数是操作系统层面的
ulimit -n 20000

再次通过ab压测,通过访问status,发现依然不尽人意。

猜你喜欢

转载自blog.csdn.net/dataiyangu/article/details/88963159