nginx网络优化设置

① 如何配置Nginx做高可用

Nginx配置
Nginx 的配置主要是修改 /usr/local/nginx/conf/nginx,conf文件
#配置用户和用户组
user www www;
#工作进程数，建议设置为CPU的总核数
worker_processes 2;
#全局错误日志定义类型，日志等级从低到高依次为： debug | info | notice | warn | error | crit
error_log logs/error.log info;
#记录主进程ID的文件
pid /usr/local/nginx/nginx.pid;
#一个进程能打开的文件描述符最大值，理论上该值因该是最多能打开的文件数除以进程数。但是由于nginx负载并不是完全均衡的，
#所以这个值最好等于最多能打开的文件数。执行 sysctl -a | grep fs.file 可以看到linux文件描述符。
worker_rlimit_nofile 65535;
#工作模式与连接数上限
events {
#工作模式，linux2.6版本以上用epoll
use epoll;
#单个进程允许的最大连接数
worker_connections 65535;
}
#设定http服务器，利用它的反向代理功能提供负载均衡支持
http {
#文件扩展名与文件类型映射表
include mime.types;
#默认文件类型
default_type application/octet-stream;
#日志格式
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
#access log 记录了哪些用户，哪些页面以及用户浏览器、ip和其他的访问信息
access_log logs/access.log main;
#服务器名字的hash表大小
server_names_hash_bucket_size 128;
#客户端请求头缓冲大小。nginx默认会用client_header_buffer_size这个buffer来读取header值，
#如果header过大，它会使用large_client_header_buffers来读取。
#如果设置过小HTTP头/Cookie过大 会报400 错误 nginx 400 bad request
#如果超过buffer，就会报HTTP 414错误(URI Too Long)
#nginx接受最长的HTTP头部大小必须比其中一个buffer大，否则就会报400的HTTP错误(Bad Request)。
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;
#客户端请求体的大小
client_body_buffer_size 8m;
#隐藏ngnix版本号
server_tokens off;
#忽略不合法的请求头
ignore_invalid_headers on;
#指定启用除第一条error_page指令以外其他的error_page。
recursive_error_pages on;
#让 nginx 在处理自己内部重定向时不默认使用 server_name 设置中的第一个域名
server_name_in_redirect off;
#开启文件传输，一般应用都应设置为on；若是有下载的应用，则可以设置成off来平衡网络I/O和磁盘的I/O来降低系统负载
sendfile on;
#告诉nginx在一个数据包里发送所有头文件，而不一个接一个的发送。
tcp_nopush on;
#告诉nginx不要缓存数据，而是一段一段的发送--当需要及时发送数据时，就应该给应用设置这个属性，
#这样发送一小块数据信息时就不能立即得到返回值。
tcp_nodelay on;
#长连接超时时间，单位是秒
keepalive_timeout 65;
#gzip模块设置，使用 gzip 压缩可以降低网站带宽消耗，同时提升访问速度。
gzip on; #开启gzip
gzip_min_length 1k; #最小压缩大小
gzip_buffers 4 16k; #压缩缓冲区
gzip_http_version 1.0; #压缩版本
gzip_comp_level 2; #压缩等级
gzip_types text/plain application/x-javascript text/css application/xml; #压缩类型
#upstream作负载均衡，在此配置需要轮询的服务器地址和端口号，max_fails为允许请求失败的次数，默认为1.
#weight为轮询权重，根据不同的权重分配可以用来平衡服务器的访问率。
upstream hostname {
server 192.168.2.149:8080 max_fails=0 weight=1;
server 192.168.1.9:8080 max_fails=0 weight=1;
}
#主机配置
server {
#监听端口
listen 80;
#域名
server_name hostname;
#字符集
charset utf-8;
#单独的access_log文件
access_log logs/192.168.2.149.access.log main;
#反向代理配置，将所有请求为http://hostname的请求全部转发到upstream中定义的目标服务器中。
location / {
#此处配置的域名必须与upstream的域名一致，才能转发。
proxy_pass http://hostname;
proxy_set_header X-Real-IP $remote_addr;
}
#启用nginx status 监听页面
location /nginxstatus {
stub_status on;
access_log on;
}
#错误页面
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
至此，nginx基本的负载均衡配置完成，实验中部署2台tomcat, 然后访问时返回不同的结果，在浏览器中输入地址，确实能看到不同的返回结果。nginx配置文件的内容还有待于继续学习。

② nginx调优，怎么优化性能

可优化点：
work_processes 8； 【根据你的CPU配置的，你的E5-2650是八核】
error_log logs/error.log error; 【运行状态，尽量不使用info，日志量太多太大，占用IO】
use epoll； 【考虑使用epoll模式，提高并发量】
send timeout 1m; 【等待时间缩小，减少排队】

③ 如何调整nginx服务器的性能

当linux下Nginx达到并发数很高，TCP TIME_WAIT套接字数量经常达到两、三万，这样服务器很容易被拖死。事实上，我们可以简单的通过修改Linux内核参数，可以减少Nginx服务器的TIME_WAIT套接字数量，进而提高Nginx服务器并发性能。

vi /etc/sysctl.conf

增加以下几行：
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000简单说明：
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout = 30 表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。
net.ipv4.tcp_keepalive_time = 1200 表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。
net.ipv4.ip_local_port_range = 1024 65000 表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。
net.ipv4.tcp_max_syn_backlog = 8192 表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets = 5000 表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000，改 为5000。对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME_WAIT套接字数量，但是对于Squid，效果却不大。此项参 数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死。

echo “====================== 执行以下命令使配置生效：=========================”
#更改linux内核参数后，立即生效的命令！

/sbin/sysctl -p

Nginx优化

使用FastCGI 缓存
fastcgi_cache TEST
开启FastCGI 缓存并且为其制定一个名称。个人感觉开启缓存非常有用，可以有效降低CPU 负载，并且防止502 错误。

fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2
keys_zone=TEST:10m
inactive=5m;
这个指令为FastCGI 缓存指定一个路径，目录结构等级，关键字区域存储时间和非活动删除时间

其它说明

Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，它已经在该站点运行超过两年半了。Igor 将源代码以类BSD许可证的形式发布。

在高并发连接的情况下，Nginx是Apache服务器不错的替代品。Nginx同时也可以作为7层负载均衡服务器来使用。根据我的测试结 果，Nginx 0.6.31 + PHP 5.2.6 (FastCGI) 可以承受3万以上的并发连接数，相当于同等环境下Apache的10倍。

根据我的经验，4GB内存的服务器+Apache（prefork模式）一般只能处理3000个并发连接，因为它们将占用3GB以上的内存，还 得为系统预留1GB的内存。我曾经就有两台Apache服务器，因为在配置文件中设置的MaxClients为4000，当Apache并发连接数达到 3800时，导致服务器内存和Swap空间用满而崩溃。

而这台 Nginx 0.6.31 + PHP 5.2.6 (FastCGI) 服务器在3万并发连接下，开启的10个Nginx进程消耗150M内存（15M*10=150M），开启的64个php-cgi进程消耗1280M内存 （20M*64=1280M），加上系统自身消耗的内存，总共消耗不到2GB内存。如果服务器内存较小，完全可以只开启25个php-cgi进程，这样 php-cgi消耗的总内存数才500M。

④ Nginx需要优化哪些内容

body{ line-height:200%;font-size:14px } 为了获得更大的性能，有必要对Nginx服务器进行优化。 1.关闭访问日志 关闭Nginx的访问日志，如果确定需要记录日志，那么可以根据实际需要有选择地记录部分日志，Nginx的访问日志可以具体到“区段”级别。 2.使用epoll 这是在Linux下必选的模型，但是epoll只能使用于Linux内核2.6版本及以后的系统。对于我们现在使用的Linux系统这不是问题，从Red Hat4以后的系统都是2.6内核子。 3.Nginx服务器配置优化 worker_connections 65535 keepalive_timeout 60 client_header_buffer_size 8k worker_rlimit_nofile 65535

⑤ nginx 配置详解是什么

Nginx是lgor Sysoev为俄罗斯访问量第二的rambler.ru站点设计开发的。从2004年发布至今，凭借开源的力量，已经接近成熟与完善。

Nginx功能丰富，可作为HTTP服务器，也可作为反向代理服务器，邮件服务器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。并且支持很多第三方的模块扩展。

Nginx的稳定性、功能集、示例配置文件和低系统资源的消耗让他后来居上，在全球活跃的网站中有12.18%的使用比率，大约为2220万个网站。

1、全局块：配置影响nginx全局的指令。一般有运行nginx服务器的用户组，nginx进程pid存放路径，日志存放路径，配置文件引入，允许生成worker process数等。

2、events块：配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个网路连接，开启多个网络连接序列化等。

3、http块：可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。如文件引入，mime-type定义，日志自定义，是否使用sendfile传输文件，连接超时时间，单连接请求数等。

4、server块：配置虚拟主机的相关参数，一个http中可以有多个server。

5、location块：配置请求的路由，以及各种页面的处理情况。

Nginx常用功能。

1、Http代理，反向代理：作为web服务器最常用的功能之一，尤其是反向代理。

Nginx在做反向代理时，提供性能稳定，并且能够提供配置灵活的转发功能。Nginx可以根据不同的正则匹配，采取不同的转发策略，比如图片文件结尾的走文件服务器，动态页面走web服务器，只要你正则写的没问题，又有相对应的服务器解决方案。

。并且Nginx对返回结果进行错误页跳转，异常判断等。如果被分发的服务器存在异常，他可以将请求重新转发给另外一台服务器，然后自动去除异常服务器。

2、负载均衡

Nginx提供的负载均衡策略有2种：内置策略和扩展策略。内置策略为轮询，加权轮询，Ip hash。扩展策略，就天马行空，只有你想不到的没有他做不到的啦，你可以参照所有的负载均衡算法，给他一一找出来做下实现。

⑥ 高并发nginx，需要注意哪些配置

参考下面的《nginx配置高并发》

一、一般来说nginx配置文件中对优化比较有作用的为以下几项：
1.worker_processes8;
nginx进程数，建议按照cpu数目来指定，一般为它的倍数(如,2个四核的cpu计为8)。
2.worker_cpu_00;
为每个进程分配cpu，上例中将8个进程分配到8个cpu，当然可以写多个，或者将一
个进程分配到多个cpu。
3.worker_rlimit_nofile65535;
这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文
件数（ulimit-n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit-n的值保持一致。
现在在linux2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应应该填写65535。
这是因为nginx调度时分配请求到进程并不是那么的均衡，所以假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。
查看linux系统文件描述符的方法：
[root@web001~]#sysctl-a|grepfs.file
fs.file-max=789972
fs.file-nr=5100789972
4.useepoll;
使用epoll的I/O模型
(
补充说明:
与apache相类，nginx针对不同的操作系统，有不同的事件模型
A）标准事件模型
Select、poll属于标准事件模型，如果当前系统不存在更有效的方法，nginx会选择select或poll
B）高效事件模型
Kqueue：使用于FreeBSD4.1+,OpenBSD2.9+,NetBSD2.0和MacOSX.使用双处理器的MacOSX系统使用kqueue可能会造成内核崩溃。
Epoll:使用于Linux内核2.6版本及以后的系统。
/dev/poll：使用于Solaris711/99+,HP/UX11.22+(eventport),IRIX6.5.15+和Tru64UNIX5.1A+。
Eventport：使用于Solaris10.为了防止出现内核崩溃的问题，有必要安装安全补丁。
)
5.worker_connections65535;
每个进程允许的最多连接数，理论上每台nginx服务器的最大连接数为worker_processes*worker_connections。
6.keepalive_timeout60;
keepalive超时时间。
7.client_header_buffer_size4k;
客户端请求头部的缓冲区大小，这个可以根据系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。
分页大小可以用命令getconfPAGESIZE取得。
[root@web001~]#getconfPAGESIZE
4096
但也有client_header_buffer_size超过4k的情况，但是client_header_buffer_size该值必须设置为“系统分页大小”的整倍数。
8.open_file_cachemax=65535inactive=60s;
这个将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存。
9.open_file_cache_valid80s;
这个是指多长时间检查一次缓存的有效信息。
10.open_file_cache_min_uses1;
open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive时间内一次没被使用，它将被移除。

二、关于内核参数的优化：
net.ipv4.tcp_max_tw_buckets=6000
timewait的数量，默认是180000。
net.ipv4.ip_local_port_range=102465000
允许系统打开的端口范围。
net.ipv4.tcp_tw_recycle=1
启用timewait快速回收。
net.ipv4.tcp_tw_reuse=1
开启重用。允许将TIME-WAITsockets重新用于新的TCP连接。
net.ipv4.tcp_syncookies=1
开启SYNCookies，当出现SYN等待队列溢出时，启用cookies来处理。
net.core.somaxconn=262144
web应用中listen函数的backlog默认会给内核参数的net.core.somaxconn限制到128，而nginx定义的NGX_LISTEN_BACKLOG默认为511，所以有必要调整这个值。
net.core.netdev_max_backlog=262144
每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
net.ipv4.tcp_max_orphans=262144
系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，孤儿连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单的DoS攻击，不能过分依靠它或者人为地减小这个值，更应该增加这个值(如果增加了内存之后)。
net.ipv4.tcp_max_syn_backlog=262144
记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M内存的系统而言，缺省值是1024，小内存的系统则是128。
net.ipv4.tcp_timestamps=0
时间戳可以避免序列号的卷绕。一个1Gbps的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉。
net.ipv4.tcp_synack_retries=1
为了打开对端的连接，内核需要发送一个SYN并附带一个回应前面一个SYN的ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃连接之前发送SYN+ACK包的数量。
net.ipv4.tcp_syn_retries=1
在内核放弃建立连接之前发送SYN包的数量。
net.ipv4.tcp_fin_timeout=1
如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是60秒。2.2内核的通常值是180秒，3.可以按这个设置，但要记住的是，即使机器是一个轻载的WEB服务器，也有因为大量的死套接字而内存溢出的风险，FIN-WAIT-2的危险性比FIN-WAIT-1要小，因为它最多只能吃掉1.5K内存，但是它们的生存期长些。
net.ipv4.tcp_keepalive_time=30
当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时。

三、下面贴一个完整的内核优化设置:
vi/etc/sysctl.confCentOS5.5中可以将所有内容清空直接替换为如下内容:
net.ipv4.ip_forward=0
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.default.accept_source_route=0
kernel.sysrq=0
kernel.core_uses_pid=1
net.ipv4.tcp_syncookies=1
kernel.msgmnb=65536
kernel.msgmax=65536
kernel.shmmax=68719476736
kernel.shmall=4294967296
net.ipv4.tcp_max_tw_buckets=6000
net.ipv4.tcp_sack=1
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_rmem=4096873804194304
net.ipv4.tcp_wmem=4096163844194304
net.core.wmem_default=8388608
net.core.rmem_default=8388608
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.netdev_max_backlog=262144
net.core.somaxconn=262144
net.ipv4.tcp_max_orphans=3276800
net.ipv4.tcp_max_syn_backlog=262144
net.ipv4.tcp_timestamps=0
net.ipv4.tcp_synack_retries=1
net.ipv4.tcp_syn_retries=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_mem=94500000915000000927000000
net.ipv4.tcp_fin_timeout=1
net.ipv4.tcp_keepalive_time=30
net.ipv4.ip_local_port_range=102465000
使配置立即生效可使用如下命令：
/sbin/sysctl-p

四、下面是关于系统连接数的优化
linux默认值openfiles和maxuserprocesses为1024
#ulimit-n
1024
#ulimit–u
1024
问题描述：说明server只允许同时打开1024个文件，处理1024个用户进程
使用ulimit-a可以查看当前系统的所有限制值，使用ulimit-n可以查看当前的最大打开文件数。
新装的linux默认只有1024，当作负载较大的服务器时，很容易遇到error:toomanyopenfiles。因此，需要将其改大。

解决方法：
使用ulimit–n65535可即时修改，但重启后就无效了。（注ulimit-SHn65535等效ulimit-n65535，-S指soft，-H指hard)
有如下三种修改方式：
1.在/etc/rc.local中增加一行ulimit-SHn65535
2.在/etc/profile中增加一行ulimit-SHn65535
3.在/etc/security/limits.conf最后增加：
*softnofile65535
*hardnofile65535
*softnproc65535
*hardnproc65535
具体使用哪种，在CentOS中使用第1种方式无效果，使用第3种方式有效果，而在Debian中使用第2种有效果
#ulimit-n
65535
#ulimit-u
65535

备注：ulimit命令本身就有分软硬设置，加-H就是硬，加-S就是软默认显示的是软限制
soft限制指的是当前系统生效的设置值。hard限制值可以被普通用户降低。但是不能增加。soft限制不能设置的比hard限制更高。只有root用户才能够增加hard限制值。

五、下面是一个简单的nginx配置文件：
userwwwwww;
worker_processes8;
worker_cpu_
01000000;
error_log/www/log/nginx_error.logcrit;
pid/usr/local/nginx/nginx.pid;
worker_rlimit_nofile204800;
events
{
useepoll;
worker_connections204800;
}
http
{
includemime.types;
default_typeapplication/octet-stream;
charsetutf-8;
server_names_hash_bucket_size128;
client_header_buffer_size2k;
large_client_header_buffers44k;
client_max_body_size8m;
sendfileon;
tcp_nopushon;
keepalive_timeout60;
fastcgi_cache_path/usr/local/nginx/fastcgi_cachelevels=1:2
keys_zone=TEST:10m
inactive=5m;
fastcgi_connect_timeout300;
fastcgi_send_timeout300;
fastcgi_read_timeout300;
fastcgi_buffer_size4k;
fastcgi_buffers84k;
fastcgi_busy_buffers_size8k;
fastcgi_temp_file_write_size8k;
fastcgi_cacheTEST;
fastcgi_cache_valid2003021h;
fastcgi_cache_valid3011d;
fastcgi_cache_validany1m;
fastcgi_cache_min_uses1;
fastcgi_cache_use_staleerrortimeoutinvalid_headerhttp_500;
open_file_cachemax=204800inactive=20s;
open_file_cache_min_uses1;
open_file_cache_valid30s;
tcp_nodelayon;
gzipon;
gzip_min_length1k;
gzip_buffers416k;
gzip_http_version1.0;
gzip_comp_level2;
gzip_typestext/plainapplication/x-javascripttext/cssapplication/xml;
gzip_varyon;
server
{
listen8080;
server_namebackup.aiju.com;
indexindex.phpindex.htm;
root/www/html/;
location/status
{
stub_statuson;
}
location~.*.(php|php5)?$
{
fastcgi_pass127.0.0.1:9000;
fastcgi_indexindex.php;
includefcgi.conf;
}
location~.*.(gif|jpg|jpeg|png|bmp|swf|js|css)$
{
expires30d;
}
log_formataccess'$remote_addr--$remote_user[$time_local]"$request"'
'$status$body_bytes_sent"$http_referer"'
'"$http_user_agent"$http_x_forwarded_for';
access_log/www/log/access.logaccess;
}
}

⑦ nginx怎样配置支持2千个连接

过去谈过一些关于Nginx的常见问题; 其中有一些是关于如何优化Nginx. 很多Nginx新用户是从Apache迁移过来的，因些他们过去常常调整配置和执行魔术操作来确保服务器高效运行.
有一些坏消息要告诉你, 你不能像Apache一样优化Nginx.它没有魔术配置来减半负载或是让PHP运行速度加快一倍. 高兴的是, Nginx已经优化的非常好了. 当你决定使用Nginx并用apt-get,yum或是make命令安装的时候它就已经进行了最佳优化. (注意那些库经常过期,Wiki的安装页面上通常有最新的库)
就是说,很多影响Nginx行为的参数其默认值并不是完全适合高并发的情况. 我们也要考虑Nginx运行所在的平台,优化我们的操作系统当有一些限制的时候.
总的来说,我们无法优化单个连接的负载时间，但是我们可以确保Nginx的高并发处理环境.当然, 对于高并发我指的是每秒数百个请求连接，大多数人不需要了解这些.假如你太好奇或是想知道那就继续读吧.
首先，我们需要认识到Nginx几乎可能需要在所有的平台上使用，MacOS，Linux，FreeBSD，Solaris，Windows甚至一些更深奥的系统。他们大部分(这么翻译好些)实现了高性能的基于事件的polling方法，不幸的是Nginx的只支持其中4个系统。在四个系统中我倾向于FreeBSD，但你不会看到太大的性能差异，所以选择的操作系统让你用起来顺手，比选择最优化的操作系统更重要(参考舟的第一段翻译的很好)
我想你一定猜到了windows不在其中. Windows上的nginx确实没有什么理由让你值得使用. Windows有自己的一套处理事件polling. 所以nginx的作者选择了不支持. 因此默认的还是使用select() 这种不是很高效而且性能会下降很多的方式.(初次翻译不是很好希望多多指教)
第二个最大的限制, 也是大多数人会遇到的问题是和操作系统相关的. 打开一个shell窗口, 使用su命令切换到Nginx的运行用户, 运行命令`ulimit -a`. 这些值也会在Nginx在运行中对它进行限制. 在许多操作系统中, open files 的值是相当有限的, 在我使用的操作系统中, 它的值是 1024. 如果Nginx在运行中操作了这个限制他会记录error log(24: Too many open files) 接着返回一个操作给客户端.??当然Nginx可以处理的文件数可以更大你也可以针对操作系统做一些改动, 你可以放心的去增加这个值.
两种方式可以实现, 你可以通过ulimit设置os的: open files , 你还可以通过(nginx)配置?worker_rlimit_nofile?来申明你期望的值.
Nginx 限制
除了注意操作系统的限制, 现在我来深入到Nginx本身,看看一些指令和方法,我们可以用它来调整Nginx.
Worker Processes(用英文会更好一些)
worker_process?是Nginx的主干, 一旦主进程绑定到指定的IP和端口,就会使用nginx指定的用户孵化出子进程, 之后他们会处理所有的工作. Workers 不是多线程的, 所以不能扩展它超过CPU的核数. 所以我们应该理解设置多个( 1)workers的原理, 通常一个CPU核对应一个worker. 过犹不及,2-4个workers会伤害CPU, 在CPU成为问题之前Nginx会遇到其他的瓶颈.而通常你只是看到了空闲的进程.(这段翻的太烂了希望大家多多改进)
当你正在处理下面这种情况, 你有很多的阻塞(blocking)磁盘IO,这是你可以适当增加worker_process的值. 你需要针您的配置进行测试,检查静态文件的等待时间(waiting time), 如果值比较大,可以适当的增加worker_process.(这段翻译完有想哭的感觉)
Worker Connections
worker_connections?是个稍稍有点怪的概念. 我不是很了解这个指令的目的, 但是它有效的限制了在同一时间内每个worker可以维护的连接数. 如果我没猜错的话, 这个配置是为了确保在keep-alive配置不正确的情况下, 当你使用的端口将要耗尽之时,增加连接数.(这个翻译的好难不知道是否正确因为作者也是forced to guess 我也只能被逼去猜了望指正)
默认的值是1024. 我们假设一个李兰奇一般情况下打开2个连接来通过管道获取网站资源,也就是最多可以同时处理512个用户的请求.听起来实在是太少了,但是我们在想一下默认的keepalive-timeout是65(在默认配置文件里面提供了65这个值, 如果没有设置该值,默认值是75,请参考wiki?keepalive_timeout),也就是说我们实际上每秒只能处理8个连接. 显然这个值高于许多人期望的(我没觉得高呵呵),
To using The pack procrastinated and manageable ed medications review I. Skin canada pharmacy online the: did This. Trying viagra Very loved like with. Eyelashes viagra online You with. Hair bit, moisture generic online pharmacy expensive don't the The. Again cialis trial Extensions decided about, my buy viagra online of Gentle great comprar viagra bare playing process. Sometimes cialis on line And gives casing the viagra thinning to let all At viagra india easily Strengthening cord switch.
尤其是考虑到我们通常会设置2-4个workers. 但是对于流量较大的网站 使用keep-alive是值得的.(翻译完了又想哭了)
此外，我们还必须考虑反向代理, 这将打开一个额外的连接到后台，但是，自Nginx的不支持持久连接到后台，这不是太大的问题，除非你有长时间运行的后台进程.
所有关于worker连接的配置应该是相当清楚的，如果你流量增加了，你要相应的增加worker连接的数量。 2048对于大多数人来说应该是满足了,但老实说，如果你的流量增长了,那么对于workers的数量值应该是多少应该是很清楚的.
CPU 优先级
设置CPU的优先级，基本上意味着你告诉每个程序使用的CPU核心，而他们将只使用这个CPU核心。关于这一条，我不想说很多，但你要知道，如果你准备这样做，则必须非常小心。 要知道，你操作系统的 CPU 调度器处理负载均衡的能力要远远超过你。当然，如果你认为你的 CPU 负载均衡有问题，在调度层面上优化它，可能的话找一个替代的调度器。除非你知道你在做什么，否则不要碰这个。
Keep Alive
keep_alive?是 HTTP的一个特性, 它允许客户端维护与服务器已经创建的连接进行一批请求的处理直到指定的超时时间到达. 这个实际上不会在很大程度上改变我们的Nginxserver的性能, 因为Nginx能够很好的处理空闲的连接. Nginx的作者声称10,000个空闲的连接智慧使用2.5兆内存(unbelievable), 我个人的使用来说这个值也是靠谱的.
我在这篇性能文章里面提到这个原因非常简单. 对于最终用户来说keep alive对加载时间有着巨大的影响. 这是最重要的指标之一也是我们不断优化的原因.如果你的网站对用户来说感觉加载起来很快,他们就会很开心. Amazon和一些其他的大型在线零售商做过许多类似的研究表明, 网站的加载时间和网站订单的完成有着直接的关系.
为什么keep alive有着如此巨大的影响, 应该是显而易见的, 那就是你避免为所有的HTTP请求创建各自的连接, 这是非常低效的. 也许你不需要把keepalive-timeout设置为65, 但是10-20应该是比较通用的选择,正如上面一段所说, Nginx会很好的处理这方面.
tcp_nodelay 和 tcp_nopush
这两个指令也许是最难理解的nginx配置, 他们对于nginx的影响在网络的较低层. 你可以简单的认为这些指令决定了操作系统如何处理网络缓存和他们何时将这些缓存输出到最终用户(客户端). 我只能建议大家如果你之前不了解这些概念你最好不要动它. 他们不会显着的改善或者改变性能, 所以最好使用他们的默认值.
硬件限制
因为我们要处理nginx带来的所有可能的限制, 所以我们现在需要弄清楚如何有效的利用我们的服务器.为了做到这点我们需要看一下硬件层面的东西,由于大部分服务器瓶颈都会发生在这里.
一般服务器主要还有3个方面的瓶颈. CPU,内存和IO. Nginx在CPU的利用方面是非常高效的, 所以我会坦白的告诉你这不会成为瓶颈. 同样nginx在使用内存方面也是很高效的,这也不会成为瓶颈. 现在只剩下IO这个服务器瓶颈的罪魁祸首了.(搞得像找罪犯一样)
如果你经常使用服务器，那么你可能经历过这样认识。硬盘驱动器是真的，真的很慢。从硬盘驱动器读取可能是对服务器最昂贵的操作. 所以自然得出的结论是，为了避免IO瓶颈, 我们需要大量的减少nginx对硬盘驱动器的读写.
要做到这一点，我们可以通过修改Nginx的行为，以减少磁盘写操作，以及确保对nginx的内存限制，允许它避免磁盘访问。
Access Logs
默认情况下，Nginx的每个请求都会记录在磁盘上的日志文件中，你可以使用这个方法进行统计，安全问题检查等, 带着这会在一定程度上带来IO使用成本. 如果你不打算用这些访问日志来做一些检查或其他用途, 你可以直接关闭它以避免对磁盘写操作, 但是如果你需要访问日志,你可以考虑保存日志到内存中.这将会比直接写到磁盘上快很多,并且明显减少IO的使用.
如果你只打算使用访问日志进行统计,你可以考虑使用其他的比如google analytics来取代(ga和access log还是有区别的 不能简单的取代哦),或者你只记录访问请求的部分信息而不是全部.
Error Logs
我内心小小的挣扎了一把,我是否要在这里阐述这个error log 指令呢,因为也许你根本不希望关闭error log, 特别是考虑到实际应用中错误日志的量会很少. 但是考虑到这里指令有一个小小的地方需要引起大家注意, 错误日志的等级参数你是可以指定的, 如果你指定的太低了他会记录404错误甚至是debug信息. 在实际的应用中可以将它设置为warn级别,将会是绰绰有余的并且能降低IO.
Open File Cache
?从文件系统中读取文件由2部分组成,打开和关闭文件. 考虑到这是一个有阻塞的操作,因此不要忽略这部分. 因此, 对于我们来说缓存打开文件的描述符是非常好的,这就是open_file_cache指令的由来. 链接的wiki地址里对于使用和配置它有着非常好的说明, 所以我建议你去拜读一下.
Buffers
配置Nginx缓存的大小是一个非常重要的事情. 如果缓存大小设置的太小, Nginx将不得不把上游(用英文upsteams会更好)的相应结果存放到临时的缓存文件里面,这将会同时增加IO的读写操作, 而且流量越大问题越多.
client_body_buffer_size指令用来指定处理客户端请求的缓冲区大小,?这个代表了访问请求的body. 这是用来处理POST的数据,也就是通过提交表单,文件上传等请求的数据. 如果你需要处理很多大的POST请求的,你必须确保缓存区要设置的足够大.
fastcgi_buffers?和?proxy_buffers?指令用来处理上流(upstream)的响应结果, 也就是PHP Apache等.它的概念其实和上面提到的差不多, 如果缓冲区不足够大数据将在返回给用户使用之前被保存到磁盘上. 注意Nginx将这个buffer数据同步的传输给客户端之前,有一个缓存上限, 保存到磁盘也同样受限. 这个上线是通过fastcgi_max_temp_file_size和proxy_max_temp_file_size来设置的. 另外对于代理的连接你也可以通过把proxy_buffering设置成off来彻底的关闭缓存.(通常这不是一个好办法).
彻底移除磁盘IO
最好的减少磁盘IO的方法无疑是不使用磁盘, 如果你的的应用只有少量的数据传输,你可以将数据都放入内存,这样就可以彻底不用考虑磁盘IO的阻塞了. 当然默认情况下你的操作系统也会缓存频繁访问的磁盘扇区, 所以内存越大磁盘的IO就会用到的越少. 这就意味着你可以通过增加内存来解决IO的瓶颈. 数据量越多,需要的内存越大.
网络IO
为了好玩,我们假设你有了足够大的内存来缓存你的所有数据. 这意味着理论上你的IO读速度达到了3-6gbps. 但是你没有那么快的网络通道. 不幸的是,我们可以优化的网络IO是有限的,我们要通过网络传输数据,所以还将受制于网络IO. 唯一真正有效的方法是尽量减少数据量或压缩。
幸运的是Nginx提供了gzip模块, 它可以使我们在将数据传输给客户端之前压缩它, 这将大大减少数据的大小. 一般来说 gzip_comp_level的值不会在性能方面有多大的差别,设为为4-5即可. 一味的增加它是没有意义的只是浪费的CPU的周期.
你也可以通过一些javascript和css缩小工具来减少传输文件大小. 但这些不是和Nginx很相关所以我相信你通过google可以获取更多的相关信息.

⑧ 如何利用Nginx的缓冲，缓存优化提升性能

反向代理的一个问题是代理大量用户时会增加服务器进程的性能冲击影响。在大多数情况下，可以很大程度上能通过利用Nginx的缓冲和缓存功能减轻。
当代理到另一台服务器，两个不同的连接速度会影响客户的体验：
从客户机到Nginx代理的连接。
从Nginx代理到后端服务器的连接。
Nginx具有优化这些连接调整其行为的能力。
如果没有缓冲，数据从代理的服务器发送并立即开始被发送到客户。如果假定客户端很快，缓冲可以关闭而尽快使数据到客户端，有了缓冲，Nginx 代理将暂时存储后端的响应，然后按需供给数据给客户端。如果客户端是缓慢的，允许Nginx服务器关闭到后端的连接。然后，它可以处理数据分配到客户端， 以任何可能的速度。
Nginx默认有缓冲设计，因为客户端往往有很大的不同的连接速度。我们可以用以下指令调节缓冲行为。可以在HTTP，server或 location位置来设置。重要的是要记住，大小size指令是针对每个请求配置的，所以增加超出你需求会影响你的性能，如果这时有许多客户端请求：
proxy_buffering：该指令控制缓冲是否启用。默认情况下，它的值是“on”。
proxy_buffers：该指令控制代理响应缓冲区的数量（第一个参数）和大小（第二个参数）。默认配置是8个缓冲区大小等于一个内存页（4K或者8K）。增加缓冲区的数目可以让你缓冲更多信息。
proxy_buffer_size：从后端服务器的响应头缓冲区大小，它包含headers，和其他部分响应是分开的。该指令设置响应部分的缓冲区大小。默认情况下，它和proxy_buffers是相同的尺寸，但因为这是用于头信息，这通常可以设置为一个较低的值。
proxy_busy_buffers_size：此指令设置标注“client-ready”缓冲区的最大尺寸。而客户端可以一次读取来自一个缓冲区的数据，缓冲被放置在队列中，批量发送到客户端。此指令控制允许是在这种状态下的缓冲空间的大小。
proxy_max_temp_file_size：这是每个请求能用磁盘上临时文件最大大小。这些当上游响应太大不能装配到缓冲区时被创建。
proxy_temp_file_write_size：这是当被代理服务器的响应过大时Nginx一次性写入临时文件的数据量。
proxy_temp_path：当上游服务器的响应过大不能存储到配置的缓冲区域时，Nginx存储临时文件硬盘路径。
正如你所看到的，Nginx提供了相当多的不同的指令来调整缓冲行为。大多数时候，你不必担心太多，但它对于调整一些值可能是有用的。可能最有用的调整是proxy_buffers和proxy_buffer_size指令。

⑨ 您好，我的论坛linux nginx服务器 速度有些慢，请问有优化方法吗

一、编译安装过程优化

1.减小Nginx编译后的文件大小
在编译Nginx时，默认以debug模式进行，而在debug模式下会插入很多跟踪和ASSERT之类的信息，编译完成后，一个Nginx要有好几兆字
节。在编译前取消Nginx的debug模式，编译完成后Nginx只有几百千字节，因此可以在编译之前，修改相关源码，取消debug模式，具体方法如
下：
在Nginx源码文件被解压后，找到源码目录下的auto/cc/gcc文件，在其中找到如下几行：
# debug CFLAGS=”$CFLAGS -g”

注释掉或删掉这两行，即可取消debug模式。

2.为特定的CPU指定CPU类型编译优化
在编译Nginx时，默认的GCC编译参数是“-O”，要优化GCC编译，可以使用以下两个参数：
--with-cc-opt='-O3'
--with-cpu-opt=CPU #为特定的 CPU 编译，有效的值包括：pentium, pentiumpro, pentium3, pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64
要确定CPU类型，可以通过如下命令:
[root@localhost home]#cat /proc/cpuinfo | grep "model name"

二、利用TCMalloc优化Nginx的性能
TCMalloc的全称为Thread-Caching
Malloc，是谷歌开发的开源工具“google-perftools”中的一个成员。与标准的glibc库的malloc相比，TCMalloc库在
内存分配效率和速度上要高很多，这在很大程度上提高了服务器在高并发情况下的性能，从而降低系统负载。下面简单介绍如何为Nginx添加TCMalloc
库支持。
要安装TCMalloc库，需要安装libunwind（32位操作系统不需要安装）和google-perftools两个软件包，libunwind
库为基于64位CPU和操作系统的程序提供了基本函数调用链和函数调用寄存器功能。下面介绍利用TCMalloc优化Nginx的具体操作过程：

1.安装libunwind库
可以从http://download.savannah.gnu.org/releases/libunwind下载相应的libunwind版本，这里下载的是libunwind-0.99-alpha.tar.gz，安装过程如下：

[root@localhost home]#tar zxvf libunwind-0.99-alpha.tar.gz [root@localhost home]# cd libunwind-0.99-alpha/ [root@localhost libunwind-0.99-alpha]#CFLAGS=-fPIC ./configure [root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC [root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC install

2.安装google-perftools
可以从http://google-perftools.googlecode.com下载相应的google-perftools版本，这里下载的是google-perftools-1.8.tar.gz，安装过程如下：

[root@localhost home]#tar zxvf google-perftools-1.8.tar.gz [root@localhost home]#cd google-perftools-1.8/ [root@localhost google-perftools-1.8]# ./configure [root@localhost google-perftools-1.8]#make && make install [root@localhost google-perftools-1.8]#echo "/usr/local/lib" > /etc/ld.so.conf.d/usr_local_lib.conf [root@localhost google-perftools-1.8]# ldconfig

至此，google-perftools安装完成。

3.重新编译Nginx
为了使Nginx支持google-perftools，需要在安装过程中添加“–with-google_perftools_mole”选项重新编译Nginx，安装代码如下：

[[email protected]]#./configure \ >--with-google_perftools_mole --with-http_stub_status_mole --prefix=/opt/nginx [root@localhost nginx-0.7.65]#make [root@localhost nginx-0.7.65]#make install

到这里Nginx安装完成。

4.为google-perftools添加线程目录
创建一个线程目录，这里将文件放在/tmp/tcmalloc下，操作如下：

[root@localhost home]#mkdir /tmp/tcmalloc [root@localhost home]#chmod 0777 /tmp/tcmalloc

5.修改Nginx主配置文件
修改nginx.conf文件，在pid这行的下面添加如下代码：

#pid logs/nginx.pid; google_perftools_profiles /tmp/tcmalloc;

接着，重启Nginx，完成google-perftools的加载。

6.验证运行状态
为了验证google-perftools已经正常加载，通过如下命令查看：

[root@ localhost home]# lsof -n | grep tcmalloc nginx 2395 nobody 9w REG 8,8 0 1599440 /tmp/tcmalloc.2395 nginx 2396 nobody 11w REG 8,8 0 1599443 /tmp/tcmalloc.2396 nginx 2397 nobody 13w REG 8,8 0 1599441 /tmp/tcmalloc.2397 nginx 2398 nobody 15w REG 8,8 0 1599442 /tmp/tcmalloc.2398

由于在Nginx配置文件中，设置worker_processes的值为4，因此开启了4个Nginx线程，每个线程会有一行记录。每个线程文件后面的数字值就是启动的Nginx的PID值。
至此，利用TCMalloc优化Nginx的操作完成。

三、Nginx内核参数优化
内核参数的优化，主要是在Linux系统中针对Nginx应用而进行的系统内核参数优化，常见的优化参数值如下。
下面给出一个优化实例以供参考：
net.ipv4.tcp_max_tw_buckets = 6000 net.ipv4.ip_local_port_range = 1024 65000 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_syncookies = 1 net.core.somaxconn = 262144 net.core.netdev_max_backlog = 262144 net.ipv4.tcp_max_orphans = 262144 net.ipv4.tcp_max_syn_backlog = 262144 net.ipv4.tcp_synack_retries = 1 net.ipv4.tcp_syn_retries = 1 net.ipv4.tcp_fin_timeout = 1 net.ipv4.tcp_keepalive_time = 30
将上面的内核参数值加入/etc/sysctl.conf文件中，然后执行如下命令使之生效：
[root@ localhost home]#/sbin/sysctl -p
下面是对实例中选项的含义进行介绍：
 net.ipv4.tcp_max_tw_buckets参数用来设定timewait的数量，默认是180000，这里设为6000。
 net.ipv4.ip_local_port_range选项用来设定允许系统打开的端口范围。
 net.ipv4.tcp_tw_recycle选项用于设置启用timewait快速回收。
 net.ipv4.tcp_tw_reuse选项用于设置开启重用，允许将TIME-WAIT sockets重新用于新的TCP连接。
 net.ipv4.tcp_syncookies选项用于设置开启SYN Cookies，当出现SYN等待队列溢出时，启用cookies进行处理。
 net.core.somaxconn选项默认值是128， 这个参数用于调节系统同时发起的tcp连接数，在高并发的请求中，默认的值可能会导致链接超时或者重传，因此，需要结合并发请求数来调节此值。
 net.core.netdev_max_backlog选项表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许发送到队列的数据包的最大数目。
 net.ipv4.tcp_max_orphans选项用于设定系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数
字，孤立连接将立即被复位并打印出警告信息。这个限制只是为了防止简单的DoS攻击。不能过分依靠这个限制甚至人为减小这个值，更多的情况是增加这个值。
 net.ipv4.tcp_max_syn_backlog选项用于记录那些尚未收到客户端确认信息的连接请求的最大值。对于有128MB内存的系统而言，此参数的默认值是1024，对小内存的系统则是128。
 net.ipv4.tcp_synack_retries参数的值决定了内核放弃连接之前发送SYN+ACK包的数量。
 net.ipv4.tcp_syn_retries选项表示在内核放弃建立连接之前发送SYN包的数量。
 net.ipv4.tcp_fin_timeout选项决定了套接字保持在FIN-WAIT-2状态的时间。默认值是60秒。正确设置这个值非常重要，有时候即使一个负载很小的Web服务器，也会出现因为大量的死套接字而产生内存溢出的风险。
 net.ipv4.tcp_keepalive_time选项表示当keepalive启用的时候，TCP发送keepalive消息的频度。默认值是2（单位是小时）。

⑩ nginx 配置详解是怎么样的

Nginx配置文件主要分为四部分：main（全局配置）、server（主机设置）、upstream（上游服务器设置）和location(URL匹配特定位置后的设置）每部分包含若干个指令。

Nginx功能丰富，可作为HTTP服务器，也可作为反向代理服务器，邮件服务器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。

并且支持很多第三方的模块扩展，Nginx的稳定性、功能集、示例配置文件和低系统资源的消耗让他后来居上，在全球活跃的网站中有12.18%的使用比率，大约为2220万个网站。

nginx 配置注意事项

Nginx可以对不同的文件做不同的缓存处理，配置灵活，并且支持FastCGI_Cache，主要用于对FastCGI的动态程序进行缓存。配合着第三方的ngx_cache_purge，对制定的URL缓存内容可以的进行增删管理。

events块：配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个网路连接，开启多个网络连接序列化等。