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伺服器或與用戶的網路連接。有每個進程的最大連接數，選取哪種事件驅動模型處理連接請求，是否允許同時接受多個網路連接，開啟多個網路連接序列化等。