web單機優化

又得開始寫博客了，目測又要一週一篇了，固然了這不算python跟前端的，我的喜歡notepad++惋惜不能放圖片，word什麼的太討厭了

 

爲何要單機優化呢，很簡單，由於不論之後是各種集羣也好，物理機虛擬機也好，只有將我的優點發揮到最大才能提高總體的最低限度，由於木桶原理嘛；再一個，窮啊，玩linux那就是得優化，極盡的壓榨操做系統的性能。集羣什麼的都是從單機演化出來的，so，優化好單機是你繼續下一步的初始條件

 

咱們從一個請求鏈接的總流程來看一下咱們可優化的點（運維角度）

 

 

 

其實這中間的每個步驟速度提高都對咱們的性能有提高（此時的性能是指用戶的客觀感覺，就是開你網頁快不快），每次網站變卡了，領導就說去趕快加點帶寬去，這句話也是對的，帶寬大了，數據發送的時間就會變少，加帶寬確定是對性能提高有好處的，so如今知道了大家老大其實也是很專業的了吧~~~

好了，不賣萌了，做爲專業的運維，咱們確定是但願花合適的時間金錢在最合適的提高位置，這也就是所謂的 「瓶頸點」，所以作優化，找出「瓶頸點」最爲關鍵！可是很是惋惜咱們只能從本身的服務器這面進行優化的進行，由於找出「瓶頸點」這就是一個很現實的事情了，紙上談兵，毫無心義。

 

所以，進入今天的主題吧，單機web性能優化！

徹底單機的web實際上是不容易針對優化的，由於全部的服務都須要安放在一臺機器上，常見的就是咱們喜歡的lnmp，一臺電腦上要裝nginx、php、mysql，可能還有一些其餘的什麼鬼，so，我萌只能進行一些通用的優化了。

 

一.從系統自己限制考慮

先從咱們的服務器自己考慮，咱們須要使用ulimit 這個熟悉的命令將每一個進程能夠打開的文件數目加大到65535（默認值1024）並更改系統可打開的總文件數目，爲何要改這玩意？because on Linux everything is file，so，we must do it！仍是不理解，好吧，每當建立一個鏈接後，這讓條鏈接都會打開若干文件，哪怕至少咱們也要打開一個小socket，這樣就會佔用一個文件，若是鏈接過多，而單個任務上有限制只容許一共打開1024個文件，那麼後面的鏈接就進不來了。同理，若是全部任務打開的文件數超過了系統自己容許的上限也不行，因此file-max也是尤其重要的，二者缺一不可！

1 [root@master ~]# ulimit -n
2 1024
3 [root@master ~]# ulimit -n 65535
4 [root@master ~]# ulimit -n
5 65535
6 [root@master ~]# cat /proc/sys/fs/file-max
7 181795
8 [root@master ~]# echo "fs.file-max = 6553560" >>/etc/sysctl.conf

二. 提供的服務類型考慮

咱們對外提供web服務，那麼我走的確定是http/https鏈接了，對內我本身的業務須要鏈接本身的數據庫，，so，總的來講我走的就是tcp鏈接，既然如此咱們先回顧下經典的三握四揮吧

 

 

流程及三次握手相關的就不說了就那麼幾下，直接總結揮手重要的

time_wait出如今客戶端主動斷開鏈接後

close_wait出如今服務端主動斷開鏈接後

其實time_wait是不太好，並且他在斷開後仍是會留有一個2分鐘的文件，這樣就佔用了上面的可打開文件數資源！so，咱們從這一點進行相關優化，首先，咱們要思考下爲何鏈接斷開了，默認仍是會保留狀態呢，寫tcp協議這哥們是否是傻，是否是傻，你以爲他是否是傻？其實不是，人家只是基於當時的環境考慮了一些問題：

1. 防止上一次鏈接的包在網絡傳輸中迷路了，要把它收回來
2. TCP不是UDP，要保證可靠性！在主動關閉方發送的最後一個 ack(fin) ，有可能丟失，這時被動方會從新發fin, 若是這時主動方處於 CLOSED 狀態 ，就會響應 rst 而不是 ack。因此主動方要處於 TIME_WAIT 狀態，而不能是 CLOSED！
3. 另外這麼設計TIME_WAIT 會定時的回收資源，並不會佔用很大資源的，除非短期內接受大量請求或者受到攻擊

固然，這是基於當年的網絡環境下的考慮，1981年的網絡情況大約4分鐘你傳輸一個byte！so不解釋了（我怎麼知道的？由於我會穿越時空啊，我剛纔還去買了幾瓶82年的雪碧呢~），可是這不是咱們就不優化的理由呀，so，咱們有三個內核參數來解決這個問題。

 

1. tcp_tw_reuse複用，畢竟每次建立TCP鏈接是須要消耗資源的，若是TIME-WAIT sockets能複用那真的很不錯，咱們能夠在任何地方開啓它
2. tcp_tw_recycle快速銷魂，它在內網環境下會很給力，可讓你快速回收TIME_WAIT sockets，可是它有一個問題就是不能夠在NAT負載均衡器上打開
3. tcp_timestamps是上面兩個選項的基礎條件，不過默認狀況下是已經打開的，它就是在打一個時間戳，咱們須要一個標識來肯定sockets是否該被回收或是複用

 

1 [root@master ~]# cat /proc/sys/net/ipv4/tcp_tw_reuse
2 0
3 [root@master ~]# cat /proc/sys/net/ipv4/tcp_timestamps
4 1
5 [root@master ~]# cat /proc/sys/net/ipv4/tcp_tw_recycle
6 0
7 [root@master ~]# echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
8 [root@master ~]# echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

再從最簡單的方面考慮下，咱們不就是以爲TIME_WAIT 的時間太長了麼，那麼咱們把它直接改小不就能夠了麼，改過小也很差，會引發其餘問題

1 [root@master ~]# echo 15 > /proc/sys/net/ipv4/tcp_fin_timeout

文件限制方面的優化如今貌似這樣就很不錯哦，如今咱們不考慮這面單純的就是想提升該web的併發量，怎麼破，咱們都知道創建鏈接後是兩臺機器端口間的互相傷害，so，若是咱們能夠多開一些端口，有人會問，多開端口那是客戶端的問題，你服務端開個80別人連你不都走這個麼，這就是架構的魅力所在，在你是服務器的同時，你又是客戶端，你提供web就單純是個html麼，不須要交互數據庫嘛，不須要拿靜態資源嘛，靜態資源可能也有個服務器，so，任重而道遠啊，多有一些可打開的端口是一件美好的事情了吧

1 [root@master ~]# cat /proc/sys/net/ipv4/ip_local_port_range 
2 32768    60999
3 [root@master ~]# echo "10000 65530" > /proc/sys/net/ipv4/ip_local_port_range

三.組件分離

當服務徹底都在一臺機器上時，咱們確定會隨着業務量的增多進行分離，通常會先將數據庫分離，而後再將靜態資源分離。

一會兒整齊了許多，咱們有了3臺服務器，在購買服務器的時候咱們就能夠針對業務挑選性價比更高的服務器，咱們的應用服務器不須要存儲什麼東西，so磁盤什麼的就能夠從簡，數據庫那必須ssd了，如今已經很便宜了，對io的提高是極其明顯的，而文件服務器，用ssd也好，可是cpu跟內存就不須要太關注了。

當咱們的機器分離出來後，已經給咱們的併發量帶來了提高，每一個服務都是要佔文件描述符的，如今分離出來，各自佔本機的，沒人跟你搶，還有可以使用的端口。

咱們先優化數據庫跟文件服務器，他們都須要對磁盤進行大量的io操做，因此咱們要對磁盤調度方式進行調整，linuxIO調度你們都知道的，基本知識

Cfq：徹底公平，默認選項

Noop:什麼都不作，ssd就用這個

Deadline:有一個最後期限，數據庫經常使用

So，很明顯咱們的文件服務器在使用了ssd盤後就能夠將其的盤符的調度改爲Noop了，而web服務器可能就是記錄下日誌，因此使用默認的Cfq就好。而數據庫服務器使用Deadline，那麼請問使用了ssd的數據庫改用Deadline仍是Noop？答案其實都是能夠的，其實這二者之間性能差異不大，可是因爲數據庫的性質，設置一個最後期限仍是更加合理。

最後咱們優化咱們的web服務器，以nginx爲例，

高級配置：

worker_processes auto;

Events配置：

use epoll;

worker_connections 65535

HTTP配置：

sendfile on;

tcp_nopush on;

tcp_nodelay on;

前幾個就不說了，tcp_nopush與tcp_nodelay的意義是相對的，可是在開啓sendfile的狀況下並不衝突，簡單的說最終的效果就是會將發送的數據一直積累到最大報文長度後再發送，若是是最後的包那麼會直接發送不等待。這裏面牽扯tcp協議裏的東西

 Nagle算法是指知足最大報文長度狀況下，馬上發送，不然放在緩衝區，減小網絡中包的數量提高性能

DelayedAcknowledgment再也不針對單個包發送ACK，而是一次確認兩個包，或者在發送響應數據的同時捎帶着發送ACK，又或者觸發超時時間後再發送ACK，經過減小網絡中的ack數量提高網絡環境

可是長鏈接出現奇數包+結束小包時，就會對前兩個包很快的進行正常處理，可是第三個包的ack並未返回而是被先緩存起來了，而發送端須要確認此包的ack才能髮結束小包結束所有鏈接，so，須要延遲40ms過時時間纔會發送，而後結束鏈接，從而下降了性能。

在短鏈接中不會出現這種狀況，由於鏈接是讀---寫---讀---寫，馬上結束的，由於馬上結束了鏈接，so最後的包是馬上發出的