高性能網站服務器的架設優化
一：對於高性能網站 ,請求量大,如何支撐?思路
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
高性能網站服務器的架設優化