转自:http://my.oschina.net/hyperichq/blog/399792点击打开链接
常用优化要点
nginx使用的是固定数量的workers, 每个worker都处理进入的请求。最佳实践是每个CPU内核配置一个worker.
如何知道您的系统有几个CPU?
1
|
$
grep
^processor
/proc/cpuinfo
|
wc
-l
|
对于一个四核处理器,配置文件类似:
# One worker per CPU-core.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
worker_processes 4;
events {
worker_connections 8096;
multi_accept on;
use epoll;
}
worker_rlimit_nofile 40000;
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 15;
# Your content here ..
}
|
这里我们提高了 worker_connections 设置,定义了每个worker进程能处理多少连接。
服务器的最大连接数量是:
1
|
worker_processes * worker_connections (= 32384 本例中)
|
这里启用了 multi_accept,该配置项使
nginx能尽快接收尽可能多的请求,减少客户端的连接初始化时间。
最后,本例中使用了 epoll
的事件模型,这也是最佳实践建议。
压缩
很多用户会启用 gzip压缩模块,使得返回客户端的内容更简短,传输更快。
但是压缩会消耗用户服务器资源,通过监控CPU使用率(可采用开源Hyperic),如果过高,可以考虑禁用压缩。
通常只压缩大文件,避免压缩那些压缩效果不好的文件,例如图片,可执行文件等二进制文件。
用户可参考下面配置:
1
2
3
4
5
6
|
gzip
on;
gzip_vary on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text
/plain
text
/css
text
/xml
text
/javascript
application
/x-javascript
application
/xml
;
gzip_disable
"MSIE [1-6]\."
;
|
上面配置,只对文件大于10k的文本文件进行压缩。
客户端缓存
如果客户端(一般是浏览器)认为已经保存了要下载的最新内容,就不会向nginx服务器再发请求。
这需要做一些缓存设置。最简单的办法是将所有的图片,js等静态内容设置一个固定的时间长度:
1
2
3
4
5
|
location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
access_log off;
log_not_found off;
expires 30d;
}
|
这里我们也禁用了媒体文件的日志,将一些文件后缀文件的过期时间设置为30天。
文件句柄缓存
如果需要处理大量静态文件,需要保持这些文件句柄为打开状态,避免后续再次打开。
下面示例,既可放在nginx配置的 server 部分,也可放在主 http 块中。:
1
2
3
4
|
open_file_cache max=2000 inactive=20s;
open_file_cache_valid 60s;
open_file_cache_min_uses 5;
open_file_cache_errors off;
|
这里设置服务器最大缓存2000个打开的文件句柄,关闭20秒内无请求的文件句柄,句柄的有效时间是60秒,并且只有访问次数超过5次的才会被缓存。这样只缓存频繁访问的文件,降低文件系统的访问。
优化PHP
很多站点使用了PHP,例如drupal, wordpress。
由于nginx没有自己的mod_php,推荐的方式是使用 PHP-FPM,需要将请求转发,例如:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# execute all .php files via php-fpm
location ~ .php$ {
# connect to a unix domain-socket:
fastcgi_pass unix:
/var/run/php5-fpm
.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_buffer_size 128k;
fastcgi_buffers 256 16k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
# This file is present on Debian systems..
include fastcgi_params;
}
|
注意这里使用了 Unix domain-socket 连接 FPM, 所以需要修改/etc/php5/fpm/pool.d/www.conf 如下:
1
|
listen =
/var/run/php5-fpm
.sock
|
这保证FPM监听一个domain socket,而不是默认的( "listen=127.0.0.1:9000
").
默认的PHP-FPM将启动一些专用的worker,每个运行一个PHP实例。如果内存足够,可以增加worker数量来提升并发吞吐量。
编辑文件 /etc/php5/fpm/pool.d/
www.conf,改变数量,例如:
1
2
3
4
|
;
set
a fixed number of php workers
pm = static
; start up 12 php processes
pm.max_children = 12
|
该值需要根据实际环境调整。调整的依据是使用监控工具所采集的数据。
最后可配置PHP-FPM自动重启。如果出现问题,例如下面的配置是,在1分钟内十个子进程死掉,就重启,允许进程有十秒失去控制。
下面是/etc/php5/fpm/php-fpm.conf 中的全局配置
:
1
2
3
|
emergency_restart_threshold 10
emergency_restart_interval 1m
process_control_timeout 10s
|
检验
优化配置的效果需要实践检验,建议部署一个监控工具,监控的内容应包括:
Nginx:开源版提供的监控指标,仅有如下6个:
Connections,Accepts,Handled,Requests,Writing,Waiting
从操作系统的角度:应包括Nginx进程的CPU使用率,内存占用,整体CPU使用率,交换区使用率等指标。
如果是在虚拟机上运行,还应关注 操作系统的 ST( Steal Time)指标,判断是否有超卖,过载等现象;
这里推荐一个免费开源工具, Hyperic