文章目录
大访问量优化整体思路
高性能的服务器的架设
对于高性能网站 ,请求量大,如何支撑?
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 系统层面
- 最大连接数
//这一proc目录下的都是process，即系统运行状态，不是真正的文件，都是状态值。
more /proc/sys/net/core/somaxconn
128
//修改这个值
echo 50000 > /proc/sys/net/core/somaxconn
- 加快tcp连接的回收
cat /proc/sys/net/ipv4/tcp_tw_recycle
0
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
- 空的tcp是否允许回收利用reuse
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
- 不做洪水攻击的抵御
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又非常少了。