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

1,要减少请求

对于开发人员----合并css, 背景图片, 减少mysql查询等.

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

3: 利用cdn来响应请求

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

所以,来到第4步后,就不要再考虑减少请求这个方向了，根据业务需求来选择服务器，是IO大点的选择更好的磁盘。而是思考如何更好的响应高并发请，既然响应是不可避免的,我们要做的是把工作内容”平均”分给每台服务器，最理想的状态是每台服务器的性能都被充分利用.

二：优化思路

nginx响应请求无非就两种情况：

排查问题,也要注意观察这两点,

1:建立socket连接

2: 打开文件,并沿socket返回.

三：优化过程

1:判断nginx的瓶颈

1.1: 首先把ab测试端的性能提高,使之能高并发的请求.

易出问题: too many open files

原因 :  ab在压力测试时,打开的socket过多

解决: ulimit -n 30000 (重启失效)

观察结果: nginx 不需要特殊优化的情况下, 5000个连接,1秒内响应.满足要求,但 wating状态的连接过多.

1.2: 解决waiting进程过多的问题.

解决办法: keepalive_timeout = 0; 

即: 请求结果后,不保留tcp连接.在高并发的情况下, keepalive会占据大量的socket连接.

结果: waiting状态的连接明显减少.

由上图可看出,nginx的问题容易出在2点上:

1: nginx接受的tcp连接多,能否建立起来?

2: nginx响应过程,要打开许多文件 ,能否打开?

第1个问题: 在内核层面(见下)

第2个问题 (见下)

系统内核层面:

net.core.somaxconn = 4096 允许等待中的监听

net.ipv4.tcp_tw_recycle = 1  tcp连接快速回收

net.ipv4.tcp_tw_reuse = 1    tcp连接重用  

net.ipv4.tcp_syncookies = 0  不抵御洪水攻击

net.ipv4.tcp_fin_timeout = 15   控制tcp连接时间

net.ipv4.tcp_keepalive_time = 600  控制tcp连接超时时间
net.ipv4.tcp_synack_retries = 2   握手状态重试次数，默认5
net.ipv4.tcp_max_syn_backlog = 8192  送到队列的数据包的最大数目

ulimit -n 30000   打开文件数

Nginx层面:

worker_processes 24;    =cpu的核数

worker_connections  10240;　　连接数　　

Worker_rlimit_nofiles 10000;   nginx可打开文件数

Keepalive_timeout 0;

gzip on; 　　压缩设置.减少网络传输数据量.

location ~ .+\.(htm|html|css|swf|xml|gif|png|jpg|class|ico|mp3|zip|rar|mp4|flv|exe|txt|ff|mod|atf)?$ {
expires 7d;
}                         利用location规则进行expires 图片浏览器缓存

Nginx---->php-fpm之间的优化

如上图,在很多个nginx来访问fpm时, fpm的进程要是不够用, 会生成子进程.

生成子进程需要内核来调度,比较耗时,

如果网站并发比较大,

我们可以用静态方式一次性生成若干子进程,保持在内存中.

方法 -- 修改php-fpm.conf

Pm = static  让fpm进程始终保持,不要动态生成

Pm.max_children= 50  始终保持的子进程数量

群集方面

利用nginx反向代理方式 平均分摊请求，做内网转发。

upstream qinyujie { #定义负载均衡站点名称　　
　　　　　　　　server 192.168.0.161:80;
　　　　　　　　server 192.168.0.162:80;    #后端真实ip一般指内网　　
　　　　　　}

#proxy_pass http://192.168.7.133:8080;

proxy_pass http://qinyujie;  　　#配置代理站点或后端真实ip

高性能网站服务器的架设优化