高性能網站服務器的架設優化-Nginx優化

一：對於高性能網站 ,請求量大,如何支撐?思路

在網站架構設計中，你們必定對 LNMP (Linux Nginx Mysql Php) 不陌生。
LNMP 確實是一個很是優秀的架構，秉承着自由，開放，高效，易用的設計理念.利用它構建大型Web

 

如上圖所示。瀏覽器向Web服務器發送http請求以前，須要先創建鏈接。沒錯，它們間創建鏈接的過程跟咱們平時開發socket程序相似。由此可知，HTTP協議的「無鏈接」特性並非指：瀏覽器與Web服務器進行數據交換時，不須要創建鏈接。那麼「無鏈接」特性到底指什麼呢？咱們再看圖1會發現，瀏覽器每次請求完畢後都會與服務器處於「斷開」狀態，下一次請求時再從新與服務器創建鏈接。HTTP的無鏈接特性偏偏就是指瀏覽器的每次請求都必須從新與服務器創建鏈接，正常狀況下，瀏覽器不會與Web服務器保持長時間的鏈接狀態。若是多用戶訪問次數太高服務器吃不消怎麼辦？那咱們就要想辦法 來解決，從兩個大方面來講：一方面減小用戶請求次數，另外一方面優化服務器。

若是要減小請求，

1.對於開發人員----能夠合併css, 背景圖片, 減小mysql查詢等分庫分表.不一樣數據庫不一樣服務器訪問，這樣服務器壓力不會太大。

2: 對於運維 nginx的expires ,利用瀏覽器緩存.jpg、png、css等,減小查詢.

3: 利用cdn來響應請求緩存.

4: 最終剩下的,不可避免的請求----服務器集羣+負載均衡來支撐.（LVS/Haproxy/Nginx）

因此,來到第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的核數

client_max_body_size 20m; 上傳一些較大的文件會報403，

worker_connections  10240;　　鏈接數　　

Worker_rlimit_nofiles 10000;   nginx可打開文件數

Keepalive_timeout 0;

gzip on; 　　壓縮設置.減小網絡傳輸數據量.

gzip_min_length 1k;
gzip_buffers 4 8k;
gzip_http_version 1.0;
gzip_comp_level 5;
gzip_vary on;
gzip_types text/plain application/x-javascript text/css application/xml;

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轉發機，利用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

 其餘能夠根據業務需求使用LVS/Haproxy