標籤:選擇 worker conf core back font ret net cookies
一:對於高效能網站 ,請求量大,如何支撐?思路
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反向 Proxy方式 平均分攤請求,做內網轉寄。
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
高效能網站伺服器的架設最佳化