【WEB】高併發Web服務的演變-節約系統內存和CPU

目前主流瀏覽器一般能夠存在2-6個併發。

鏈接和請求，佔據了服務器的大量CPU和內存等資源。在資源數目超過100+的網站頁面中，使用更多的下載鏈接，很是有必要。 

緩解「高併發」的壓力的手段。

一. Web前端優化，下降服務器壓力 

1. 減小Web請求

經常使用的實現方法是經過Http協議頭中的expire或max-age來控制，將靜態內容放入瀏覽器的本地緩存，在以後的一段時間裏，再也不請求Web服務器，直接使用本地資源。在HTML5中的本地存儲技術（LocalStorage），也被做爲一個數據本地緩存。 

2. 減輕Web請求

經過Http協議的Last-Modified或Etag來控制。 這個時候請求服務器，若是是內容沒有發生變化，服務器會放回304 Not Modified。這樣的話，就不須要每次請求web服務器都作複雜的傳輸完整數據文件的工做，只是簡單的http應答就能夠達到相同的效果。

3. 合併頁面請求

3.1 合併HTML展現內容。將CSS和JS直接嵌套入HTML頁面中，不經過鏈接的方式引入

3.2 Ajax動態內容合併請求。對於動態內容，將10次Ajax請求合併爲1次的批量信息查詢。

3.3 小圖片合併， 經過CSS的偏移量技術Sprites， 將不少小圖片合併爲一張。這個優化方式， 在PC端的Web優化中，很是常見。

二.  節約Web服務器端的內存

  前端的優化完成，咱們就須要着眼於Web服務器端自己。內存是Web服務器很是重要的資源，更多的內存一般意味着能夠同時放入更多的工做任務。就Web服務佔用內存而言，能夠粗略劃分：

1. 用來維持鏈接的基本內存，進程初始化時，會載入一些基礎模塊到內存。

2. 被傳輸的數據內容載入到各個緩衝區，佔用的內存。

  3. 程序執行過程當中，申請和使用的內存。

Apache（httpd）的工做模式中，優化內存的方法以下：

1. prefork MPM， 多進程工做模式 。

原理：主進程生成後，它先完成基礎的初始化工做，然年，經過fork預先產生一批子進程（子進程複製父進程的內存空間，不須要再作基礎的初始化工做），而後等待工做。 之因此預先生成，是爲了減小頻繁建立和銷燬進程的開銷。多進程的好處， 是進程之間的內存數據不會相互干擾，同時，某個進程異常終止也不會影響其餘進程。可是，就內存而言，每一個httpd子進程佔用了不少的內存，由於子進程的內存數據是複製父進程的。咱們能夠粗略認爲，這裏存在大量的「重複數 據」被放在內存中。最終，致使咱們可以生成的子進程最大數量是頗有限。在面對高併發時，由於有很多Keep-alive的長鏈接，將這些子進程「霸佔」住，極可能致使可用子進程耗盡。所以，prefork並不太適合高併發場景。

優勢：成熟穩定，兼容全部新老模塊。同時，不須要擔憂線程安全的問題。

缺點：一個服務進程佔用不少的內存。

2. worker MPM，多進程和多線程的混合模式

worker模式比起prefork，是使用了多進程和多線程的混合模式。它也預先fork了幾個子進程（數量不多），而後每一個子進程建立一些線程（其中包括一個監聽線程）。每一個請求過來，會被分配到1個線程來服務。線程比起進程會更輕量，由於線程一般會 共享父進程的內存空間，所以，內存的佔用會減小一些。在高併發的場景下，由於比起prefork更省內存，所以會有更多的可用線程。

3. event MPM，多進程和多線的混合模式，引入Epoll 

這個是Apache中比較新的模式，在如今的版本（Apache 2.4.10）已是穩定可用的模式。它和worker模式很像，最大的區別在於，它解決了keep-alive場景下，長期被佔用的線程的資源浪費問題。event MPM中，會有一個專門的線程來管理這些 keep-alive類型的線程，當有真實請求過來的時候，將請求傳遞給服務線程，執行完畢後，又容許它釋放。它減小了「佔據」鏈接而又不使用的資源浪費，加強了高併發場景下的請求處理能力。由於減小了「閒等」的線程，線程的數量減小，同等場景下，內 存佔用會降低一些。

4. 使用比較輕量的Nginx做爲Web服務器

5. sendfile節約內存 

四. 節約Web服務器的CPU

1. select/poll 

2. Epoll（新版的Apache的event MPM，Nginx等支持） 

Reference： http://www.admin10000.com/document/6190.html