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

文章目录

• 大访问量优化整体思路
• ab压力测试及nginx性能统计模块
• ab压力测试及nginx性能统计模块
• ab压力测试
• nginx性能统计模块
• nginx单机1w并发优化
• 整装待发：
• socket nginx曾名
• socket 系统层面
• 文件 nginx层面
• 文件 系统层面
• 再出发

大访问量优化整体思路

高性能的服务器的架设

对于高性能网站 ,请求量大,如何支撑?

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

connect 后面是并发数

//-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，发现依然不尽人意，并发数还是最多六七百。

整装待发：

socket nginx曾名

vi conf/nginx.conf
	events{
		worker_connection 10240;
	}

socket 系统层面

1. 最大连接数

//这一proc目录下的都是process，即系统运行状态，不是真正的文件，都是状态值。
more /proc/sys/net/core/somaxconn
128
//修改这个值
echo 50000 > /proc/sys/net/core/somaxconn

1. 加快tcp连接的回收

cat /proc/sys/net/ipv4/tcp_tw_recycle
0
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

1. 空的tcp是否允许回收利用reuse

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

1. 不做洪水攻击的抵御

more /proc/sys/net/ipv4/tcp_syncookies
1
echo 0 > /proc/sys/net/ipv4/tcp_syncookies

为了便于操作，直接写一个脚本。

vim tcpopt.sh
//内容如下
echo 50000 > /proc/sys/net/core/somaxconn
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
echo 0 > /proc/sys/net/ipv4/tcp_syncookies

文件 nginx层面

vi cong/nginx.conf

//在worker_process 1;下添加一行
//一个工作进程允许打开多少个文件，因为虽然从系统层面在下一节中设置的足够大，nginx不予许也不行。
worker_rlimit_nofile 10000

文件 系统层面

ulimit -n
1024
ulimit -n 50000

再出发

再次压力测试，发现很明显，并发数上去了。





失败了0次

大部分都在300ms内完成了。

再次压测

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

通过页面status发现是2000左右并发，因为ab客户端也需要设置最大连接数，nginx端没什么问题，已经配置过了，可是ab客户端没有设置，可累坏了，客户端没有那么强。

ulimit -n 30000
echo 50000 > /proc/sys/net/core/somaxconn

再次运行发现达到了4800-5000

//-c 8000个并发，-n 测试400000次请求
./bin/ab -c 8000 -n 400000 http://192.168.1.202/index.html

发现请求只有一两千

通过多个ab，再在另一个机器上启动一个ab，两个ab客户端同时进行压测，因为担心ab客户端没有那么强。

两个ab同时执行

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

最后还是只有一两千，本来应该上万的，但是没有失败的，而且百分之八十都在200ms之内完成。

通过上面可以看到nginx很容易就能达到一万的高并发，而且服务器不是很多高档的服务器。

修改一下

两个ab同时执行 ，增加了-k选项，

//-c 5000个并发，-n 测试100000次
./bin/ab -c 5000 -n 100000 -k http://192.168.1.202/index.html

发现waiting有显著的变化。

-k的作用就是keep-alive

打开开发者模式，观察 response headers 里面的 connection：keep-alive

在http1.0的时候 请求 应答 断开 ==》 请求 应答 断开

在http1.1的时候 不希望每次都断开，比如请求php之后再请求css，频繁断开不好，加入了connection：keep-alive 防止频繁的tcp握手

但是对于高并发的网站来说就是弊大于利的了，因为高并发的网站tcp很珍贵，抢不着，但是在nginx 的配置文件中

keepalive_timeout 0
# keepalive_timeout 65
//让tcp保持了65秒，都抢不着了还保持65秒？所以应该注释掉这行

在高并发中尤其注意加快tcp快速关闭回收keepalive_timeout 0

这个时候再次运行一个php页面

打开开发者模式，观察 response headers 里面的 connection：close

再次压力测试发现，waiting又非常少了。