如何配置高性能的Web服務器，如何配置web服務器，配置web服務器的方法有哪些，配置web服務器需要哪些條件？

配置web服務器的條件：

1、CPU最好是E5-26XX系列

2、內存在16G以上

3、核心：必須使用固態硬件

4、安裝護衛神. 主機大師，一鍵安裝高性能web環境。

5、帶寬最好選擇BGP

十條服務器端優化Web性能的技巧總結

提高 web 應用的性能從來沒有比現在更重要過。網絡經濟的比重一直在增長；全球經濟超過 5% 的價值是在因特網上產生的（數據參見下面的資料）。這個時刻在線的超連接世界意味著用戶對其的期望值也處于歷史上的最高點。如果你的網站不能及時的響應，或者你的 app 不能無延時的工作，用戶會很快的投奔到你的競爭對手那里。

舉一個例子，一份亞馬遜十年前做過的研究可以證明，甚至在那個時候，網頁加載時間每減少100毫秒，收入就會增加1%。另一個最近的研究特別強調一個事實，即超過一半的網站擁有者在調查中承認它們會因為應用程序性能的問題流失用戶。

網站到底需要多快呢？對于頁面加載，每增加1秒鐘就有4%的用戶放棄使用。頂級的電子商務站點的頁面在第一次交互時可以做到1秒到3秒加載時間，而這是提供最高舒適度的速度。很明顯這種利害關系對于 web 應用來說很高，而且在不斷的增加。

想要提高效率很簡單，但是看到實際結果很難。為了在你的探索之旅上幫助到你，這篇文章會給你提供10條最高可以提升10倍網站性能的建議。

Tip #1: 通過反向代理來提高性能和增加安全性

如果你的 web 應用運行在單個機器上，那么這個辦法會明顯的提升性能：只需要換一個更快的機器，更好的處理器，更多的內存，更快的磁盤陣列，等等。然后新機器就可以更快的運行你的 WordPress 服務器, Node.js 程序, Java 程序，以及其它程序。（如果你的程序要訪問數據庫服務器，那么解決方法依然很簡單：添加兩個更快的機器，以及在兩臺電腦之間使用一個更快的鏈路。）

問題是，機器速度可能并不是問題。web 程序運行慢經常是因為計算機一直在不同的任務之間切換：通過成千上萬的連接和用戶交互，從磁盤訪問文件，運行代碼，等等。應用服務器可能會抖動thrashing-比如說內存不足、將內存數據交換到磁盤，以及有多個請求要等待某個任務完成，如磁盤I/O。

你可以采取一個完全不同的方案來替代升級硬件：添加一個反向代理服務器來分擔部分任務。反向代理服務器 位于運行應用的機器的前端，是用來處理網絡流量的。只有反向代理服務器是直接連接到互聯網的；和應用服務器的通訊都是通過一個快速的內部網絡完成的。

使用反向代理服務器可以將應用服務器從等待用戶與 web 程序交互解放出來，這樣應用服務器就可以專注于為反向代理服務器構建網頁，讓其能夠傳輸到互聯網上。而應用服務器就不需要等待客戶端的響應，其運行速度可以接近于優化后的性能水平。

添加反向代理服務器還可以給你的 web 服務器安裝帶來靈活性。比如，一個某種類型的服務器已經超載了，那么就可以輕松的添加另一個相同的服務器；如果某個機器宕機了，也可以很容易替代一個新的。

因為反向代理帶來的靈活性，所以反向代理也是一些性能加速功能的必要前提，比如：

負載均衡 (參見 Tip #2) – 負載均衡運行在反向代理服務器上，用來將流量均衡分配給一批應用。有了合適的負載均衡，你就可以添加應用服務器而根本不用修改應用。

緩存靜態文件 (參見 Tip #3) – 直接讀取的文件，比如圖片或者客戶端代碼，可以保存在反向代理服務器，然后直接發給客戶端，這樣就可以提高速度、分擔應用服務器的負載，可以讓應用運行的更快。

網站安全 – 反向代理服務器可以提高網站安全性，以及快速的發現和響應攻擊，保證應用服務器處于被保護狀態。

NGINX 軟件為用作反向代理服務器而專門設計，也包含了上述的多種功能。NGINX 使用事件驅動的方式處理請求，這會比傳統的服務器更加有效率。NGINX plus 添加了更多高級的反向代理特性，比如應用的健康度檢查，專門用來處理請求路由、高級緩沖和相關支持。

Tip #2: 添加負載平衡

添加一個負載均衡服務器 是一個相當簡單的用來提高性能和網站安全性的的方法。與其將核心 Web 服務器變得越來越大和越來越強，不如使用負載均衡將流量分配到多個服務器。即使程序寫的不好，或者在擴容方面有困難，僅是使用負載均衡服務器就可以很好的提高用戶體驗。

負載均衡服務器首先是一個反向代理服務器（參見Tip #1）——它接受來自互聯網的流量，然后轉發請求給另一個服務器。特別是負載均衡服務器支持兩個或多個應用服務器，使用分配算法將請求轉發給不同服務器。最簡單的負載均衡方法是輪轉法round robin，每個新的請求都會發給列表里的下一個服務器。其它的復制均衡方法包括將請求發給活動連接最少的服務器。NGINX plus 擁有將特定用戶的會話分配給同一個服務器的能力。

負載均衡可以很好的提高性能是因為它可以避免某個服務器過載而另一些服務器卻沒有需要處理的流量。它也可以簡單的擴展服務器規模，因為你可以添加多個價格相對便宜的服務器并且保證它們被充分利用了。

可以進行負載均衡的協議包括 HTTP、HTTPS、SPDY、HTTP/2、WebSocket、FastCGI、SCGI、uwsgi、 memcached 等，以及幾種其它的應用類型，包括基于 TCP 的應用和其它的第4層協議的程序。分析你的 web 應用來決定你要使用哪些以及哪些地方性能不足。

相同的服務器或服務器群可以被用來進行負載均衡，也可以用來處理其它的任務，如 SSL 末端服務器，支持客戶端的 HTTP/1.x 和 HTTP/2 請求，以及緩存靜態文件。

Tip #3: 緩存靜態和動態的內容

緩存可以通過加速內容的傳輸速度來提高 web 應用的性能。它可以采用以下幾種策略：當需要的時候預處理要傳輸的內容，保存數據到速度更快的設備，把數據存儲在距離客戶端更近的位置，或者將這幾種方法結合起來使用。

有兩種不同類型數據的緩沖：

靜態內容緩存。不經常變化的文件，比如圖像(JPEG、PNG) 和代碼(CSS,JavaScript)，可以保存在外圍服務器上，這樣就可以快速的從內存和磁盤上提取。

動態內容緩存。很多 web 應用會針對每次網頁請求生成一個新的 HTML 頁面。在短時間內簡單的緩存生成的 HTML 內容，就可以很好的減少要生成的內容的數量，而且這些頁面足夠新，可以滿足你的需要。

舉個例子，如果一個頁面每秒會被瀏覽10次，你將它緩存 1 秒，90%請求的頁面都會直接從緩存提取。如果你分開緩存靜態內容，甚至新生成的頁面可能都是由這些緩存構成的。

下面由是 web 應用發明的三種主要的緩存技術：

1.縮短數據與用戶的網絡距離。把一份內容的拷貝放的離用戶更近的節點來減少傳輸時間。

2.提高內容服務器的速度。內容可以保存在一個更快的服務器上來減少提取文件的時間。

3.從過載服務器上移走數據。機器經常因為要完成某些其它的任務而造成某個任務的執行速度比測試結果要差。將數據緩存在不同的機器上可以提高緩存資源和非緩存資源的性能，而這是因為主機沒有被過度使用。

對 web 應用的緩存機制可以在 web 應用服務器內部實現。首先，緩存動態內容是用來減少應用服務器加載動態內容的時間。其次，緩存靜態內容（包括動態內容的臨時拷貝）是為了更進一步的分擔應用服務器的負載。而且緩存之后會從應用服務器轉移到對用戶而言更快、更近的機器，從而減少應用服務器的壓力，減少提取數據和傳輸數據的時間。

改進過的緩存方案可以極大的提高應用的速度。對于大多數網頁來說，靜態數據，比如大圖像文件，構成了超過一半的內容。如果沒有緩存，那么這可能會花費幾秒的時間來提取和傳輸這類數據，但是采用了緩存之后不到1秒就可以完成。

舉一個在實際中緩存是如何使用的例子， NGINX 和 NGINX Plus 使用了兩條指令來設置緩存機制：proxy_cache_path 和 proxy_cache。你可以指定緩存的位置和大小、文件在緩存中保存的最長時間和其它一些參數。使用第三條（而且是相當受歡迎的一條）指令 proxy_cache_use_stale，如果提供新鮮內容的服務器忙碌或者掛掉了，你甚至可以讓緩存提供較舊的內容，這樣客戶端就不會一無所得。從用戶的角度來看這可以很好的提高你的網站或者應用的可用時間。

NGINX plus 有個高級緩存特性，包括對緩存清除的支持和在儀表盤上顯示緩存狀態信息。

注意：緩存機制分布于應用開發者、投資決策者以及實際的系統運維人員之間。本文提到的一些復雜的緩存機制從 DevOps 的角度來看很具有價值，即對集應用開發者、架構師以及運維操作人員的功能為一體的工程師來說可以滿足它們對站點功能性、響應時間、安全性和商業結果（如完成的交易數）等需要。

Tip #4: 壓縮數據

壓縮是一個具有很大潛力的提高性能的加速方法。現在已經有一些針對照片（JPEG 和PNG）、視頻（MPEG-4）和音樂（MP3）等各類文件精心設計和高壓縮率的標準。每一個標準都或多或少的減少了文件的大小。

文本數據 —— 包括HTML（包含了純文本和 HTML 標簽），CSS 和代碼，比如 Javascript —— 經常是未經壓縮就傳輸的。壓縮這類數據會在對應用程序性能的感覺上，特別是處于慢速或受限的移動網絡的客戶端，產生更大的影響。

這是因為文本數據經常是用戶與網頁交互的有效數據，而多媒體數據可能更多的是起提供支持或者裝飾的作用。智能的內容壓縮可以減少 HTML，Javascript，CSS和其它文本內容對帶寬的要求，通常可以減少 30% 甚至更多的帶寬和相應的頁面加載時間。

如果你使用 SSL，壓縮可以減少需要進行 SSL 編碼的的數據量，而這些編碼操作會占用一些 CPU 時間而抵消了壓縮數據減少的時間。

壓縮文本數據的方法很多，舉個例子，在 HTTP/2 中，小說文本的壓縮模式就特別調整了頭部數據。另一個例子是可以在 NGINX 里打開使用 GZIP 壓縮。你在你的服務里預先壓縮文本數據之后，你就可以直接使用 gzip_static 指令來處理壓縮過的 .gz 版本。

Tip #5: 優化 SSL/TLS

安全套接字（SSL) 協議和它的下一代版本傳輸層安全（TLS）協議正在被越來越多的網站采用。SSL/TLS 對從原始服務器發往用戶的數據進行加密提高了網站的安全性。影響這個趨勢的部分原因是 Google 正在使用 SSL/TLS，這在搜索引擎排名上是一個正面的影響因素。

盡管 SSL/TLS 越來越流行，但是使用加密對速度的影響也讓很多網站望而卻步。SSL/TLS 之所以讓網站變的更慢，原因有二：

任何一個連接第一次連接時的握手過程都需要傳遞密鑰。而采用 HTTP/1.x 協議的瀏覽器在建立多個連接時會對每個連接重復上述操作。

數據在傳輸過程中需要不斷的在服務器端加密、在客戶端解密。

為了鼓勵使用 SSL/TLS，HTTP/2 和 SPDY（在下一章會描述）的作者設計了新的協議來讓瀏覽器只需要對一個瀏覽器會話使用一個連接。這會大大的減少上述第一個原因所浪費的時間。然而現在可以用來提高應用程序使用 SSL/TLS 傳輸數據的性能的方法不止這些。

web 服務器有對應的機制優化 SSL/TLS 傳輸。舉個例子，NGINX 使用 OpenSSL 運行在普通的硬件上提供了接近專用硬件的傳輸性能。NGINX 的 SSL 性能 有詳細的文檔，而且把對 SSL/TLS 數據進行加解密的時間和 CPU 占用率降低了很多。

Tip #6: 使用 HTTP/2 或 SPDY

對于已經使用了 SSL/TLS 的站點，HTTP/2 和 SPDY 可以很好的提高性能，因為每個連接只需要一次握手。而對于沒有使用 SSL/TLS 的站點來說，從響應速度的角度來說 HTTP/2 和 SPDY 將讓遷移到 SSL/TLS 沒有什么壓力（原本會降低效率）。

Google 在2012年開始把 SPDY 作為一個比 HTTP/1.x 更快速的協議來推薦。HTTP/2 是目前 IETF 通過的標準，是基于 SPDY 的。SPDY 已經被廣泛的支持了，但是很快就會被 HTTP/2 替代。

SPDY 和 HTTP/2 的關鍵是用單一連接來替代多路連接。單個連接是被復用的，所以它可以同時攜帶多個請求和響應的分片。

通過使用單一連接，這些協議可以避免像在實現了 HTTP/1.x 的瀏覽器中一樣建立和管理多個連接。單一連接在對 SSL 特別有效，這是因為它可以最小化 SSL/TLS 建立安全鏈接時的握手時間。

SPDY 協議需要使用 SSL/TLS，而 HTTP/2 官方標準并不需要，但是目前所有支持 HTTP/2 的瀏覽器只有在啟用了 SSL/TLS 的情況下才能使用它。這就意味著支持 HTTP/2 的瀏覽器只有在網站使用了 SSL 并且服務器接收 HTTP/2 流量的情況下才會啟用 HTTP/2。否則的話瀏覽器就會使用 HTTP/1.x 協議。

作為支持這些協議的一個樣例，NGINX 已經從一開始就支持了 SPDY，而且大部分使用 SPDY 協議的網站都運行的是 NGINX。NGINX 同時也很早對 HTTP/2 的提供了支持，從2015 年9月開始，開源版 NGINX 和 NGINX Plus 就支持它了。

經過一段時間，我們 NGINX 希望更多的站點完全啟用 SSL 并且向 HTTP/2 遷移。這將會提高安全性，同時也會找到并實現新的優化手段，簡化的代碼表現的會更加優異。

Tip #7: 升級軟件版本

一個提高應用性能的簡單辦法是根據軟件的穩定性和性能的評價來選在你的軟件棧。進一步說，因為高性能組件的開發者更愿意追求更高的性能和解決 bug ，所以值得使用最新版本的軟件。新版本往往更受開發者和用戶社區的關注。更新的版本往往會利用到新的編譯器優化，包括對新硬件的調優。

穩定的新版本通常比舊版本具有更好的兼容性和更高的性能。一直進行軟件更新，可以非常簡單的保持軟件保持最佳的優化，解決掉 bug，以及提高安全性。

一直使用舊版軟件也會阻止你利用新的特性。比如上面說到的 HTTP/2，目前要求 OpenSSL 1.0.1。在2016 年中期開始將會要求1.0.2 ，而它是在2015年1月才發布的。

NGINX 用戶可以開始遷移到 NGINX 最新的開源軟件 或者 NGINX Plus；它們都包含了最新的能力，如 socket 分割和線程池（見下文），這些都已經為性能優化過了。然后好好看看的你軟件棧，把它們升級到你能升級到的最新版本吧。

Tip #8: Linux 系統性能調優

Linux 是大多數 web 服務器使用的操作系統，而且作為你的架構的基礎，Linux 顯然有不少提高性能的可能。默認情況下，很多 Linux 系統都被設置為使用很少的資源，以符合典型的桌面應用使用。這就意味著 web 應用需要一些微調才能達到最大效能。

這里的 Linux 優化是專門針對 web 服務器方面的。以 NGINX 為例，這里有一些在加速 Linux 時需要強調的變化：

緩沖隊列。如果你有掛起的連接，那么你應該考慮增加 net.core.somaxconn 的值，它代表了可以緩存的連接的最大數量。如果連接限制太小，那么你將會看到錯誤信息，而你可以逐漸的增加這個參數直到錯誤信息停止出現。

文件描述符。NGINX 對一個連接使用最多2個文件描述符。如果你的系統有很多連接請求，你可能就需要提高sys.fs.file_max ，以增加系統對文件描述符數量整體的限制，這樣才能支持不斷增加的負載需求。

臨時端口。當使用代理時，NGINX 會為每個上游服務器創建臨時端口。你可以設置net.ipv4.ip_local_port_range 來提高這些端口的范圍，增加可用的端口號。你也可以減少非活動的端口的超時判斷來重復使用端口，這可以通過 net.ipv4.tcp_fin_timeout 來設置，這可以快速的提高流量。

Tip #9: web 服務器性能調優

無論你是用哪種 web 服務器，你都需要對它進行優化來提高性能。下面的推薦手段可以用于任何 web 服務器，但是一些設置是針對 NGINX 的。關鍵的優化手段包括：

訪問日志。不要把每個請求的日志都直接寫回磁盤，你可以在內存將日志緩存起來然后批量寫回磁盤。對于NGINX 來說，給指令 access_log 添加參數 buffer=size 可以讓系統在緩存滿了的情況下才把日志寫到磁盤。如果你添加了參數 flush=time ，那么緩存內容會每隔一段時間再寫回磁盤。

緩存。緩存會在內存中存放部分響應，直到滿了為止，這可以讓與客戶端的通信更加高效。內存放不下的響應會寫回磁盤，而這就會降低效能。當 NGINX 啟用了緩存機制后，你可以使用指令 proxy_buffer_size 和 proxy_buffers 來管理緩存。

客戶端保活。保活連接可以減少開銷，特別是使用 SSL/TLS 時。對于 NGINX 來說，你可以從 keepalive_requests 的默認值 100 開始增加最大連接數，這樣一個客戶端就可以在一個指定的連接上請求多次，而且你也可以通過增加 keepalive_timeout 的值來允許保活連接存活更長時間，這樣就可以讓后來的請求處理的更快速。

上游保活。上游的連接——即連接到應用服務器、數據庫服務器等機器的連接——同樣也會受益于連接保活。對于上游連接來說，你可以增加 keepalive，即每個工人進程的空閑保活連接個數。這就可以提高連接的復用次數，減少需要重新打開全新連接的次數。

限制。限制客戶端使用的資源可以提高性能和安全性。對于 NGINX 來說，指令 limit_conn 和 limit_conn_zone 限制了給定來源的連接數量，而 limit_rate 限制了帶寬。這些限制都可以阻止合法用戶扒取資源，同時也避免了攻擊。指令 limit_req 和 limit_req_zone 限制了客戶端請求。對于上游服務器來說，可以在 upstream 的配置塊里的 server 指令使用 max_conns 參數來限制連接到上游服務器的連接數。 這樣可以避免服務器過載。關聯的 queue 指令會創建一個隊列來在連接數抵達 max_connS 限制時在指定長度的時間內保存特定數量的請求。

工人進程。工人進程負責處理請求。NGINX 采用事件驅動模型和操作系統特定的機制來有效的將請求分發給不同的工人進程。這條建議推薦設置 worker_processes 為每個 CPU 一個 。worker_connections 的最大數（默認512）可以在大部分系統上根據需要增加，實驗性地找到最適合你的系統的值。

套接字分割。通常一個套接字監聽器會把新連接分配給所有工人進程。套接字分割會為每個工人進程創建一個套接字監聽器，這樣一來以當套接字監聽器可用時，內核就會將連接分配給它。這可以減少鎖競爭，并且提高多核系統的性能，要啟用套接字分隔需要在 listen 指令里面加上 reuseport 參數。

線程池。計算機進程可能被一個單一的緩慢的操作所占用。對于 web 服務器軟件來說，磁盤訪問會影響很多更快的操作，比如計算或者在內存中拷貝。使用了線程池之后慢操作可以分配到不同的任務集，而主進程可以一直運行快速操作。當磁盤操作完成后結果會返回給主進程的循環。在 NGINX 里有兩個操作——read() 系統調用和 sendfile() ——被分配到了線程池

技巧。當改變任何操作系統或支持服務的設置時，一次只改變一個參數然后測試性能。如果修改引起問題了，或者不能讓你的系統更快，那么就改回去。

Tip #10: 監視系統活動來解決問題和瓶頸

在應用開發中要使得系統變得非常高效的關鍵是監視你的系統在現實世界運行的性能。你必須能通過特定的設備和你的 web 基礎設施上監控程序活動。

監視活動是最積極的——它會告訴你發生了什么，把問題留給你發現和最終解決掉。

監視可以發現幾種不同的問題。它們包括：

服務器宕機。

服務器出問題一直在丟失連接。

服務器出現大量的緩存未命中。

服務器沒有發送正確的內容。

應用的總體性能監控工具，比如 New Relic 和 Dynatrace，可以幫助你監控到從遠程加載網頁的時間，而 NGINX 可以幫助你監控到應用交付端。當你需要考慮為基礎設施添加容量以滿足流量需求時，應用性能數據可以告訴你你的優化措施的確起作用了。

為了幫助開發者快速的發現、解決問題，NGINX Plus 增加了應用感知健康度檢查 ——對重復出現的常規事件進行綜合分析并在問題出現時向你發出警告。NGINX Plus 同時提供會話過濾功能，這可以阻止當前任務完成之前接受新的連接，另一個功能是慢啟動，允許一個從錯誤恢復過來的服務器追趕上負載均衡服務器群的進度。當使用得當時，健康度檢查可以讓你在問題變得嚴重到影響用戶體驗前就發現它，而會話過濾和慢啟動可以讓你替換服務器，并且這個過程不會對性能和正常運行時間產生負面影響。下圖就展示了內建的 NGINX Plus 模塊實時活動監視的儀表盤，包括了服務器群，TCP 連接和緩存信息等 Web 架構信息。

總結: 看看10倍性能提升的效果

這些性能提升方案對任何一個 web 應用都可用并且效果都很好，而實際效果取決于你的預算、你能花費的時間、目前實現方案的差距。所以你該如何對你自己的應用實現10倍性能提升？

為了指導你了解每種優化手段的潛在影響，這里是上面詳述的每個優化方法的關鍵點，雖然你的情況肯定大不相同：

反向代理服務器和負載均衡。沒有負載均衡或者負載均衡很差都會造成間歇的性能低谷。增加一個反向代理，比如 NGINX ，可以避免 web 應用程序在內存和磁盤之間波動。負載均衡可以將過載服務器的任務轉移到空閑的服務器，還可以輕松的進行擴容。這些改變都可以產生巨大的性能提升，很容易就可以比你現在的實現方案的最差性能提高10倍，對于總體性能來說可能提高的不多，但是也是有實質性的提升。

緩存動態和靜態數據。如果你有一個負擔過重的 web 服務器，那么毫無疑問肯定是你的應用服務器，只通過緩存動態數據就可以在峰值時間提高10倍的性能。緩存靜態文件可以提高幾倍的性能。

壓縮數據。使用媒體文件壓縮格式，比如圖像格式 JPEG，圖形格式 PNG，視頻格式 MPEG-4，音樂文件格式 MP3 可以極大的提高性能。一旦這些都用上了，然后壓縮文件數據可以將初始頁面加載速度提高兩倍。

優化 SSL/TLS。安全握手會對性能產生巨大的影響，對它們的優化可能會對初始響應產生2倍的提升，特別是對于大量文本的站點。優化 SSL/TLS 下媒體文件只會產生很小的性能提升。

使用 HTTP/2 和 SPDY。當你使用了 SSL/TLS，這些協議就可以提高整個站點的性能。

對 Linux 和 web 服務器軟件進行調優。比如優化緩存機制，使用保活連接，分配時間敏感型任務到不同的線程池可以明顯的提高性能；舉個例子，線程池可以加速對磁盤敏感的任務近一個數量級。

如何創建大型高性能Web站點

使用合適的會話管理

第一個想到的擴展系統的方法就是添加更多硬件。例如，使用兩臺服務器而不是一臺。這聽著合理，但會產生潛在問題：會話管理。這對Java程序來說是很嚴重的問題，在PHP中也會產生可延展性問題， 對于數據庫的負載尤其如此。

會話被定義為單獨的最終用戶登錄或者連接一 段時間，其中通常會包含多個TCP/IP的HTTP連接、幾個Web頁面，通常還包括幾十個甚至上百個頁面元素，如框架、菜單、Ajax更新等。所有這些 HTTP請求都需要知道用戶是誰，才能滿足安全的要求，并向用戶傳送適當的內容，因為這些都是會話的組成部分。通常每個會話都會包括相互關聯的會話數據， 如用戶名、用戶ID、歷史、購物車、統計資料等等信息。

問題在于，在有兩臺Web服務器和多個HTTP連接的情況下，用戶流量會在兩臺服務器之間分配和移動，服務器很難知道用戶是誰，并對所有數據進行跟蹤，因為每個頁面或者頁面的組成部分都可能來 自不同的服務器。在PHP中，通常是這樣解決的，在第一次連接或登錄的時候就創建一個會話ID并將其放在Cookie中，然后這個Cookie會和每個 HTTP請求一起發送。

這樣做帶來一個問題，接下來每段PHP腳本 都需要基于ID來查找會話數據。由于PHP無法在執行過程之間保持狀態（這與Java不同），這個會話數據需要存儲在某個地方，通常是在數據庫中。但是， 如果復雜的頁面需要在每個頁面載入過程中對其進行十次查找（這是經常要做的），那就意味著每個頁面都要執行10次SQL查詢，這會導致數據庫上很大的負載。

在前面所舉的中國Internet用戶 0.01%的例子中，可能很容易在每秒內僅僅為了管理會話就生成上百個查詢。解決方法是一直使用位于Cookie中的會話ID，并且使用像Memcached之類的服務來緩存會話數據以獲得高性能。

還要注 意其中存在安全性的問題，因為黑客可 以偽造另一個用戶的會話ID，這是很容易找到或看到的，特別是在公用的Wi-Fi中。解決方法是對會話ID進行恰當的加密或者簽名，并將其與時間區間、 IP地址以及其他關鍵信息 像瀏覽器或者其他細節相綁定。在Internet上有很多不錯的關于良好的會話管理的例子，你可以根據需要找到最適合的。

總是要考慮安全性

盡管編寫像防止SQL注入和登錄安全之類的 代碼涉及很多安全問題，但不幸的是，幾乎沒有人考慮過安全性，而那些考慮到的人也沒有對其進行很好地理解。而本文要關注的是操作性的系統安全。對于這類安 全，我們的焦點集中在三個安全領域：防火墻、運行的用戶以及文件訪問權限。

除了配置專門的硬件防火墻（像Cisco的 ASA）之外，所有服務器都還應該運行像Iptables之類的防火墻，它會保護服務器免受其他威脅和攻擊。這些威脅和攻擊可能來自公共的 Internet、其他服務器或本地服務器，也包括使用VPN或者SSH通道的開發和操作人員。我們僅對指定的IP開放確實需要的端口。Iptables 可能會很復雜，但是有很多不錯的模板，我們通常可以使用它們來幫助客戶創建Iptables。例如，默認的RedHat或者CentOS防火墻的配置說明 只有10行，顯然并不實用。我們最佳實踐的Iptables配置大概有5頁，這其中包含了Linux所能提供的最高級的安全防范。

所有公用的服務，都應該運行在專門的用戶 下，如Apache。切記永遠都不要使用Root用戶運行，因為這會讓任何闖入到Apache的用戶接管整個服務器。如果Apache只是運行在 Apache用戶下或者運行在Nobody下，那么闖入Apache就不是一件容易的事情了。

Web服務器運行或者服務的文件 （像.php和.html文件）對于Web服務器的用戶應該是不可寫的。這意味著Apache或者Nginx用戶不應該擁有Web目錄的寫權限。有很多方 法都可以做到這一點，而最簡單的就是將這些文件為其他用戶所有，然后讓Apache/Nginx等用戶歸屬于能夠使用640權限讀取文件的組中。這會防范 幾乎所有的黑客和針對頁面的攻擊。

此外，永遠不要使用Ftp來上傳文件，特別是在公用的Wi-Fi環境中，因為在其中黑客很容易盜取用戶名和密碼。取而代之的是使用Sftp會更加安全。另外，每個雇員都應該擁有自己的用戶ID和隨機密碼。

使用標準的路徑和安裝配置

一個令人討厭的部署問題是，開發者很少考慮 他們的軟件會被部署到生產Web服務器的什么位置，以及如何部署。我們看到過許多大型的系統將它們的PHP代碼部署在/home/xiaofeng或者 /web/code路徑下。事實上，這兩個路徑都是非常不標準的，并且會帶來操作和安全性的問題。當這些系統從開發環境轉移到測試環境再到生產環境中時， 因為每個安裝配置都是非標準的，所以經常會出現問題，這時就需要開發者調整才能夠正常工作。

你應該總是使用標準的安裝包和二進制文件來 安裝像Apache之類的服務器。不要從源代碼編譯或者安裝Tarball，因為這會導致長期穩定性和管理上的問題，另外在服務器上安裝多個不同的版本也 會造成混淆。

Web 站點應該總是在指定的平臺和 Linux發布的標準路徑下進行測試和部署，像RedHat 或者CentOS下的/var/www/html路徑。這有助于對系統進行有效的權限管 理、備份、配置、監控以及其他操作。

Web 服務器的日志應該存放在/var /logs或者/var/logs/app_name下，而不應該位于主代碼區域。這樣做的原因不僅僅是因為這些標準的路徑很重要，更應該關注的是，恰當 地配置服務器會將/var配置為分離的文件系統。如果應用程序突然寫入了大量日志并占用所有磁盤空間，由于我們做了以上的配置就不會導致系統崩潰，或者其 他嚴重的問題。如果日志位于其他位置，就可能會產生問題。

總是使用日志

在Web系統中做多少日志都不為過。所有系統都應該將重要的數據寫入到日志中，不管是它們自己的日志還是系統的Syslog。Cron的Job以及其他Shell腳本或者C語言的程序，對日志都有 相應標準以及簡單的函數。在Shell腳本中，只需要使用 Logger命令就可以實現日志的寫入。在腳本啟動/停止、重要的腳本執行以及實時數據產生的 情況下都要執行寫入日志操作。這樣出現問題的時候，查看主要的系統日志就可以很容易地看到發生了什么。

大型系統經常會使用專門的工具如 Local5來記錄日志，并配置Syslog或者Syslog-ng來將其存放在單獨的文件中，這樣會更容易使用。需要注意的是，Syslog工具和 Logger（以及任何Syslog調用）默認優先使用user.notice，如有必要，你可以對其進行調整。

一個好的系統會對程序進行配置，用來打開或者關閉日志，并可以選擇在每模塊或者功能的級別上應用不同級別的日志。這使得我們可以記錄非常詳細和強大的日志，用來分析和調試在生產操作中所發生的問題。

使用良好的數據庫設計和SQL

在任何系統中，數據庫通常是最大的性能瓶 頸。而影響數據庫性能的最大兩個問題是數據庫設計和SQL代碼質量。很多系統都擁有良好的或者至少是可用的數據庫設計，但由于沒有經過適當的性能測 試，SQL代碼質量通常都會很差。這樣的SQL代碼在開發環境中可能運行很快，因為其中只有小數據集和最小的負載。但是當成千上萬的用戶同時讀取數據庫中 上百萬條記錄的時候，它就很可能會崩潰。

不幸的 是，這些問題一開始并不明顯，直到系統增大、突然開始崩潰的時候才會顯現出來。在增大的過程中，數據庫系統看起來運行得很快（因為數據都位于內存中，而且很少有并發的查詢），并且對用戶的響 應也很快，但實際上它的內部運行效率很低。這并不重要，我們關注的是在系統增大并遇到性能問題之前找到這些問題并加以解決。

關于這個問題有很多不錯的書和站點進行了解析，其中的關鍵工具包括慢查詢日志、INNODB狀態系統，以及描述當前性能的MySQL統計信息。我們見到過很多系統每秒會讀取500,000條數據， 這是出現SQL問題的明顯預兆，但公司往往對其一無所知直到服務器開始崩潰。

MySQL系統應該對所有數據使用 INNODB存儲引擎，因為INNODB與之前的MyISAM相比，運行得更快、更穩定，并且管理性能和備份工作也更加容易和快捷。在主配置文件 中，INNODB應該被設置為默認的數據庫引擎，并且系統應該不時地進行檢查，看是否意外創建了MyISAM的表。

總要擁有良好的DB配置和備份

很多公司都沒有良好的備份機制，也不知道如 何恰當地完成這項工作。MySQL的Dump是不夠的，因為最好的備份方法是使用LVM快照和INNODB對系統進行熱備份，從而得到超快的速度和超高的 可靠性。

另外，在將所有備份文件從服務器上轉移出來 之前要進行壓縮和加密。另外還要確保擁有設計合理的MySQL配置。MySQL默認安裝使用說明中只有5~10行關于配置的說明，這根本不適合開發使用。 而我們提供給客戶的最佳實踐文檔足足有10頁那么長。文檔中大約有100種有用的關于安全、性能和穩定性問題的設定，包括防止數據敗壞，其中很多設定都是非常重要的。

使用讀/寫數據庫分離

隨著系統變得越來越龐大，特別是當它們擁有 很差的SQL時，一臺數據庫服務器通常不足以處理負載。但是多個數據庫意味著重復，除非你對數據進行了分離。更一般地，這意味著建立主/從副本系統，其中程序會對主庫編寫所有的Update、Insert和Delete變更語句，而所有Select的數據都讀取自從數據庫（或者多個從數據庫）。

盡管概念上很簡單，但是想要合理、精確地實 現并不容易，這可能需要大量的代碼工作。因此，即便在開始時使用同一臺數據庫服務器，也要盡早計劃在PHP中使用分離的DB連接來進行讀寫操作。如果正確 地完成該項工作，那么系統就可以擴展到2臺、3臺甚至12臺服務器，并具備高可用性和穩定性。

使用類似Memcached，Redis之類的數據庫緩存

即便有了好的數據庫設計、SQL和讀寫分離，大型的系統仍然需要更快的性能，特別是對會話狀態、好友列表以及BBS文字之類的東西。為了達到這個目的，我們可以使用像MemCached之類的數 據緩存，它是一個高性能的簡單數據緩存，已經被所有最大型的站點使用。但是要小心的是，不要100%依賴于一臺Memcache服務器來提高性能，因為如 果那臺服務器崩潰了，就會破壞整個系統的性能。在這種情況下，應該使用2~3臺Memcache服務器形成簇集架構，并且有選擇地包含一個緩存準備過程， 如果緩存服務器重啟，需要重新載入數據，它能夠快速地載入緩存。

構建測試和開發環境

很多公司只有開發者的桌面系統和他們的生產 服務器。當系統變得越來越大、越來越復雜時，測試和管理代碼就會導致嚴重的問題。最佳的實踐是擁有兩個測試系統，一個用于開發者的代碼和功能的整合測試， 另一個要與生產環境完全一致，從而更容易向生產環境平滑地過渡。幸運的是，現在使用云計算（或者私有云）可以輕松達到這一點。一個5~10臺服務器的生產 環境，可以很容易地在辦公室或者IDC中使用一臺服務器來復制，從而用于測試，而這臺服務器我們可以用于多個客戶的項目。

使用版本控制

要對一切使用版本控制，包括測試和生產環境的部署。很多開發者都使用SVN或者類似的方法。在理想狀態下，這些方法可以被用于所有代碼、腳本、HTML、圖片、配置、文檔和測試。版本控制應該是代碼轉移到測試環境的必經之路，而不是簡單地復制或者使用tar文件，因為這二者都是不可靠的。開發者應該將所有一切都簽入，打上標簽，然后將它們簽 出到測試系統。如果所有都沒問題，那么它們會將該版本簽出到生產環境。

分布式集群

過去當運行一個大的web應用時候意味著需要運行一個大型的web服務器。因為你的應用吸引了大量的用戶，你將不得不在你的服務器里增加更多的內存和處理器。今天，“大型服務器”模式已經過去，取而代之的是大量的小服務器，使用各種各樣的負載均衡技術。

“更多小服務器”的優勢超過過去的“大型服務器”模式體現在兩個方面：

1. 如果服務器宕機，那么負載均衡系統將停止請求到宕機的服務器，轉而分發負載到其他正常運行的服務器上。

2. 擴展你的服務器更加容易。你要做的僅僅是加入新的服務器到負載均衡系統。不需要中斷你的應用運行。

所以，把握住這個機會。當然，代價就是這要求你的應用開發時增加一點復雜度。這就是本文要覆蓋的內容。

這時你可能對自己說:“但是我怎么知道我正在使用負載均衡呢？”。最誠實的回答是，如果你正在問這個問題，那么答案是你多半沒有在使用負載均衡系統并且你的系統不需要考慮這個問題。大多數情況，當應用成長足夠大的規模時，負載均衡就需要明確提出和設置了。然而，我也偶爾看見虛擬主機公司為客戶的應用做這個負載均衡，或者像下面描述的那樣要自己來做。

注意，我一直提“web應用”而不是website,這是想區分“web應用”是那些復雜的站點往往涉及服務器端編程和數據庫，而不是website那樣只顯示簡單的靜態內容。

1. PHP文件

第一個問題是，如果你有大量的小型服務器，你怎么把你的php文件上傳到所有的服務器上？有如下的方法供你參考：

◆分別上傳所有的文件到每一個服務器 , 這種方法帶來的問題是：想像一下你有20個服務器，那么上傳過程中這將很容易導致錯誤，并且更新時極有可能導致不同服務器上有不同版本的文件。

◆使用 ‘rsync ‘ (或類似的軟件) . 這樣的工具能同步本地目錄和多個遠程主機目錄上的文件。

◆使用版本控制軟件(如subversion ) . 這是我最喜歡的方法。用它可以很好地維護我得代碼，當發布我的應用時，可以在每一個服務器上運行svn update命令同步。這種方法也使切換服務器得代碼到過去的某一個版本更加容易。

◆使用一個文件服務器(你可能發現NFS 非常適合做這件事情). 這種方式是使用一個文件服務器來存放你的web應用. 當然，如果你的文件服務器宕機，那么多所有你的站點將不能使用。這時，你就需要花費更多的開支來恢復它。

選擇哪種方式依賴于你的需求和你掌握的技能。如果你使用版本控制系統，那么你可能得計劃一個方法如果同時執行一個更新命令更新所有服務器上的代碼。然而，如果使用文件服務器，你就要實現一些失敗恢復機制，防止萬一服務器宕機導致請求失敗。

2. 文件上傳

當只有一臺服務器時，文件上傳不是一個問題。但是當我們有多臺服務器時，那么上傳的文件應該怎么存放呢？上傳文件的問題和跨服務器php文件存儲是類似的。下面是幾種可能的方案:

◆把文件存儲到數據庫中。大多數數據允許存儲二進制數據。當你請求文件下載時，訪問數據把二進制數據和相應的文件名和類型輸出給用戶。在使用這種方案前應該考慮數據庫怎樣存儲你的文件。該方法的問題在于如果數據庫服務器宕機將使文件不可用。

◆在一個文件服務器上存儲上傳的文件 . 與前面的介紹一樣，你要安裝一個文件服務器讓所有web服務器共享，把所有上傳的文件上傳到這里，上傳后所有的web服務器就都可以使用它。但是，如果文件服務器宕機，那么可能發生圖像文件下載中斷。

◆設計你自己的上傳機制傳輸文件到服務器到每一個服務器 . 這個方法沒有單個文件服務器或者數據庫方案的缺陷，但是將增加你代碼的復雜度。例如，如果上傳到多個服務器過程中，服務器宕機，你要怎么處理？

用數據庫存儲上傳文件但是設計一個文件緩存機制是一個不錯的方案。當服務器接收一個文件下載請求時，首先檢查緩存系統中是否有該文件，如果發現那么從緩存系統下載，否則從數據庫讀取并把它緩存到文件系統中。

3. 會話(Sessions)

如果你熟悉php的session 處理，你將可能知道默認情況下，它存儲session數據在服務器的臨時文件里。而且，這個文件僅僅在你請求處理的那個服務器上，但是接下來的請求可能被另外一個服務器處理，這將在另一個服務器上生成新的session。這導致session頻繁地不被識別，如登錄用戶總是要求重新登錄。

我推薦的方案是，要么重新php內建的session處理機制存儲session數據到數據庫，或者實現你自己的機制保證發送一個用戶的請求到同一臺服務器。

4. 配置(Configuration)

盡管這個話題不是和php特別相關，我感覺還是有必要提及。當運行集群服務器時，用某種方法保持服務器之間的配置文件同步是一個好主意。如果配置文件不一致，可能導致一些非常奇怪的斷斷續續的行為導致很難排查這些問題。

我推薦使用版本控制系統單獨管理他們。這樣你可以為不同的項目安裝存儲不同的php配置文件，也可以保持所有服務器配置文件同步。

5. 日志(Logging)

像配置問題一樣，logging不是僅僅和php相關。但是對于保持服務器健康運行它仍然是非常重要的。沒有正確的logging系統，你怎么知道如果PHP代碼開始產生錯誤(在系統正式運行時，你總是關閉display_errors 設置，不是嗎?)

有幾種方法你可以實現logging：

1. 在每一個服務器上記錄日志。 這是最簡單的方法。每一個機器僅僅記錄一個文件。好處是簡單，可能只要很少的配置。但是，隨著服務器數量的增多，監控每臺服務器上的日志文件將變得非常困難。

2. 記錄日志到一個共享 這種方法每一個服務器仍然有這個日志文件，但是他們通過共享機制被存儲在一個中央文件服務器上，這將使監控日志變得更簡單。該方案的問題在于，如果文件服務器不可用將導致一個簡單的日志不能寫入問題最終導致整個應用崩潰。

3. 記錄日志到logging服務器 你可以使用一個logging軟件，如syslog 來把所有的日志寫到一個中央服務器。盡管這個方法要求更多的配置，但是他也提供了最健壯的方案。