ChestNut’s Cake 好的遊戲帶領人會去關心人, 愛人, 且在神與人面前謙卑; 常常喜樂, 不住禱告, 凡事謝恩。 最重要的事就是來到上帝的面前禱告歸靈, 以致我的服侍可以把上帝的愛, 上帝的心意, 上帝的福音帶給人.

33愛的鼓勵 4訂閱站台

-----------------------重點outline------------------------------

1.          DB:

A.          能做索引的欄位一定要做

B.          Select查詢時, 指定查詢欄位會比用* 效能要高得多

2.          開發期間的開發機, 硬體設備”堪用”即可, 這樣比較可以被逼得寫出較具有效率的程式和架構

3.          但如果是遇到”編譯程式”例外, 因為編譯程式會花很多時間做編譯, 所以編譯程式的開發機, 使用較好的硬體較佳

4.          上線初期, 硬體夠用就好, 但需保留未來擴充的能力和彈性; 程式則是最好都要有擴充的能力和彈性, 包括CSS, CSS也要寫的有效率一點

5.          撰寫效能較佳的程式可以使得花費在硬體部分的費用更少些

6.          若是一般專案, 建置後就鮮少更動硬體及軟體的話, 建議”一次買齊”的方式較佳, 硬體規格也要好些以免後續不必要的問題

7.          若是像YAHOO, GOOLE等中大型網站, 網站是主要營收的, 強烈建議”後續增添配備”的方式, 用營收來擴充電腦設備, 這樣較易反虧為盈

8.          檢查頁面反應速度也是效能調校的重點之一

9.          最好是用大量的”字”搭配少量的”圖”來提升效能, 或是圖文分開存放, Loading網頁時先讓文字出來(這樣感覺比較快), 圖可再慢慢出來

10.      錢要花在刀口上, 系統上線一段時間後, 就可能會有設備損壞的問題發生, 此時就要先行預估那些設備壞的機率會較大, 或是哪些設備壞掉(ex.電源供應器)影響的損失會較大, 就要優先處理

11.      資安設備(ex.防火牆)的Throughput(I/O吞吐量), 有可能會影響到整體效能

12.      就電腦應用來說, 我們追求的是”適合”的配備, 而非”最快”的配備

13.      對於Web Server 和DB分開運行的系統架構, 可以比東西都放在同一台Server的架構, 效能更好. 在硬體變化的部分, Web Server的硬碟就不用太好, DB Server則需強調CPU運算能力和磁碟I/O效能

14.      效能的調校需要細心的觀察, 慢慢的思考問題出在哪裡, 以及身體力行的實做

---------------------------------------------------------------

一般使用者在連接各類型伺服器時，如果遇到應用程式運作起來效能不佳、反應很慢的時候，通常只會向電腦管理人員反應說『好慢』，說『好慢』兩個字很容易，調查出電腦設備與網路系統『好慢』是甚麼原因卻是個很花費時間、花費心力的事情。

這種效能調校問題，就像牙齒痛一樣，發生時真是「痛起來要人命」。若出狀況的系統是用來對外營業就會擔心客戶因此流失以及同行趁機競爭，若是對內服務系統效能不佳，則需面對來自於老闆與同事壓力。

因為電腦系統類型眾多、牽扯到的範圍太大，所以本文就以最常見「Web-Based 應用程式系統」來探討其效能瓶頸與解決方案。

Web-Based 應用程式系統

要探討 Web-Based 應用程式系統效能，就要先了解 Web-Based 應用程式系統架構，一般來說 Web-Based 系統採用３Tier 架構，分別在 Linux 與 Windows 有各自常見架構如下表：

一般可依照個人或企業需求來更換其中元件，例如將 MySQL 換成 PostgreSQL 資料庫、程式語言換成 JSP（JAVA）等等，這些若是在規劃初期就有計畫的更換，應該不致成為太大的問題。真正出現問題與狀況，會是在正式上線以後，我們不能等到正式上線才亡羊補牢，所以事前規劃更顯得重要，另外後續延展性也是底下討論重點之一。

Note：Web-Based 程式３Tier 架構如下表：

初期規劃

一個 Web-Based 系統於初期規劃是否得宜會大大影響到未來效能調校幅度與難易度，就像蓋高樓大廈要好好的規劃與架設鋼骨結構一般。因為筆者較熟悉 Linux/Unix 部份解決方案，所以底下皆以 Linux 上的應用程式來作解說。

系統架構

在開發與正式上線初期，通常只使用單一主機就可以跑所有應用程式系統，簡言之就是剛開始硬體部份只有單獨一台伺服器作所有的事情，以 Linux 為例，就是把 Apache、PHP 與 MySQL 配置得當即可。

另外較值得一提的是，在中、大型 Web-Based 系統開發專案中，程式通常會比較複雜，更新程式相對的亦會較為謹慎小心，通常會配置開發時期「測試機」與正式上線「上線主機」，習慣上會將測試機、上線主機皆使用相同等級『硬體配備』。

筆者在此建議 Web-Based 系統開發所使用「測試機」勿使用太高檔硬體配備，反而是使用一般『堪用』硬體配備即可。原因在於開發期間系統負載通常很輕、資料量與流量都很小，此時若是「不小心」撰寫出較耗用大量系統資源的程式或 SQL 命令時，會被「高效能硬體配備」所掩蓋而不容易被發現，直到「正式上線」系統負載大大提昇後，這些程式與 SQL 命令會連帶造成「高效能硬體配備」也變得運作緩慢下來，此時才回頭去查程式為何耗用大量資源，會是一件相當費時費力的事情。所以使用低廉配備的測試機，會比較容易在開發期間就發現這些問題，並順手的避免這些問題，如此會有『預防勝於治療』的效果。

Tips：使用老舊的測試機，雖是土法煉鋼，但會有『預防勝於治療』之效果。但遇到「編譯程式」例外，編譯程式通常會花費好幾分鐘以上（例如 編譯 PHP 原始程式碼），所以編譯程式還是使用較快速的硬體較佳，「執行程式」則可以在老舊測試機（堪用即可）。

硬體規劃

初期上線的主機該買到甚麼等級呢？這也是常見問題之一。這主要看初期客戶流量與未來規劃延展性而定，「錢要花在刀口上」是重點，一般來說有品牌的低階伺服器會是首選， 若預期未來會將主機放置在 Co-Location（主機設備代管）中心的話，就建議選購機架型（Rack-Mount）伺服器而避免採購塔型（Tower）機種，但若不在乎空間大小，塔型主機會算是便宜又大碗的解決方案。

近年來推行的『刀鋒伺服器』（Blade Server）其實也算是機架型伺服器，優勢是她能夠在相同空間裡，放置更多台主機（例如：７Ｕ放置１４台主機），刀鋒最適合放置在寸土寸金的都會區，或是需要很多台電腦擺在一起的叢集系統，除了「省空間」之外，她當然還有其他方面的優點，像是「省電」、「線材整齊」與「管理方便」等等。

低階伺服器您買到了甚麼呢？至少擁有 ECC（Error-correcting code，錯誤更正）級的記憶體，使得主機能夠穩定的長期開機服務，若購買機架式主機配合機櫃擺放能夠節省空間，主機Ｕ數越多可放置的磁碟就較多，但相對的Ｕ數多就比較佔空間，１Ｕ主機通常只能放置２顆硬碟（新規格可達４顆）、２Ｕ通常可放到６顆（新規格８顆），如果未來沒有外接大磁碟機（Storage）的打算，就要好好考量主機能夠放置多少磁碟的問題。

磁碟使用 SATA 或是 SCSI 價位上會有著一大段差距，但這也會關係到磁碟 I/O 速度，若是多媒體資料的 I/O 較多（圖檔、音樂檔與影片檔）且量較大，就應該考慮使用高速磁碟陣列系統，若是主司 CPU 運算的主機，其實不一定要使用到 SCSI 硬碟，另外對外的通道「網路卡」能使用 Gigabit Ethernet 會比較好，況且現在 Gigabit Ethernet 也不貴，還有若透過 Internet 連接主機，頻寬也是考慮的重點之一。

Note：初期硬體夠用就好，但須保留未來擴充的能力及彈性。

Tips：撰寫效能較佳的程式可使得花費在硬體部份的費用更少些。

網頁美工與網頁編碼規劃

網頁美工的部份若能夠妥善使用 CSS（Cascading Style Sheets，串接樣式表）技術來減少傳輸之間的資料量會更好些，如果能應用 CSS 而達到相同目的（也就是美觀），並且可以省下不少資料傳輸量的話，也是不無小補，尤其是能省下部份頻寬的費用，另外 CSS 對於整體畫面的掌控性也比較好，如此您的網站會更加的順暢。

Tips：妥善使用 CSS 不只可以用於初期規劃，也可以應用在上線之後的站台。

談到網頁美工不免的會談到『網頁編碼』，以台灣的情況來說，強烈建議使用「UTF-8」編碼方式，盡量不要再沿用以前「Big5」編碼（除非不得已），因為使用 UTF-8 對於未來作多國語言系統時會比較簡單、方便，而且 UTF-8 也沒有 Big5 編碼中的衝碼問題（許、功、蓋 …），資料庫的字元編碼理念也很類似，能存成 Unicode 就別再存成 Big5 了，不然存成 UTF-8 也好，這樣才能保有擴充性與未來性。使用 UTF-8 與 Big5 對於一般使用者最大的差別感受就是 UTF-8 可以在同一個網頁顯示不同語言文字，而 Big5 卻不行。

Tips：我們可以在 http://www.unicode.org/standard/WhatIsUnicode.html 看到各國語言的「什麽是Unicode(統一碼/標準萬國碼)?」於同一個網頁。

客戶容納數量

一開始要先預估客戶數量以及網站流量，這樣才好拿捏初期硬體配置與頻寬，這預估還關係到軟體功能與程式撰寫能力，軟體功能強大通常代表著需要更強、更快速的硬體配備，有經驗的規劃者會大概估算出「單台主機可容納的在線客戶數量」，通常一般對於硬體與頻寬選購的作法有二，而對應到適合架構也稍有不同，簡單的說：若要只用一台主機處理全部事務的小型架構，建議一次買齊、硬體則高檔些；若是多台分工的中、大型架構，硬體則夠用就好，但須保留未來擴充性。

通常若是一般專案，建置後就鮮少更動軟體及硬體的話，建議「一次買齊」方式較佳，硬體規格也要好些以免後續產生不必要的問題，若是想要作像 Yahoo、Google、維基百科（WikiPedia）與 PChome 一類的中大型網站（網站為主要營收），強烈建議「後續增添配備」的方式，這種感覺有點像先打贏了小陣仗再補充戰備，使用營收來擴充電腦設備，這樣比較容易反虧為贏，創造更高的營收與網站價值。

這其實是經營『網站』與經營『單一實體商店』很大不同的地方，單一實體店面若是生意好到要擴充需面臨到「隔壁與附近」願不願意租借給您來擴充，但虛擬世界商店擴充只要花錢買機器加頻寬，並且程式能配合擴充架構就可以了。

Tips：實體的店面擴充不易，但虛擬的店面擴充相對來說就比較簡單。

應用程式反應速度

Web-Based 應用程式與一般桌上型應用程式在「程式反應速度」方面有著很大的不同，一般人在瀏覽網頁時候通常沒什麼耐心，平均７秒左右的等待時間是合理範圍，反應時間太久客戶就自然而然的流向到同行網站。讀者可試著想想那些您常去的網站，網站營收比較好的是不是網頁反應速度都不會讓你等太久呢？不只是首頁快速，次頁的反應速度都不會相差太大，網路是一種「無遠弗屆」的介質，網路上的客戶特性就是來的快、去的也快，只要稍嫌反應速度慢，而且同行能夠取代，客戶會毫不留情的轉移到同行網站去。

Tips：所以檢查頁面反應速度也是效能調校的重要工作之一。

進階學習：用戶在選擇與使用各個網站考量的關鍵點包括「操作順手」、「收費合理」、「內容資料豐富」、「高流量瀏覽人數」及「美觀與趣味」等等，其中『操作順手』會與「使用者操作介面」、「介面邏輯流程」及「網站效能速度」有著很大的關係。

系統延展度

主要以中、大型網站會比較需要考量「系統延展度」，也就是會預期將來會有很多用戶，不論是來自於本國的用戶、或是全球用戶的網站，這類型網站通常沒辦法只使用單台主機搞定一切，所以會將網站系統切割成幾個『子單位』，在分別以主機來各司其職。若負載實在太大，則使用多台電腦作「相同或類似的事務」去分散『子單位』負載，這些方式將會應用到叢集系統（Clusters），除了叢集系統應用外，當初開發的應用程式與架構最好就預先有「中、大型系統」的準備，不然到時擴充架構，程式得重寫或大改、需要更換資料庫等等的大工程會很大大損耗成本。

考量的部份舉例來說：

• Web Server 與 Database Server 能否切割成兩台電腦運作
• 若改成多台電腦叢集架構（Clusters）後，硬體成本（伺服器、儲存設備）與軟體成本（作業系統、應用程式平台、資料庫）與所創造的營收比例是否合乎成本
• 是否未來有可能會加作多國語言服務來自於國外的客戶
• 多媒體資料（圖、音樂、影片）與純文字資料能否切割成兩台主機
• 能否使會員帳號單一簽入使用多種應用系統並且應用系統功能是模組化的（可針對模組開關），另外新增其他應用系統的未來擴充性
• 各種應用系統（拍賣、郵件信箱、部落格）未來是否有需要獨立出主機（或主機叢集）來運作

頻寬大小

對外頻寬問題算是比較容易解決的，若是主機放在 Co-Location 的話，要拓寬或縮減頻寬只是費用問題，手續上不會太複雜。若網站主機會有著大量區域網路使用者，效能瓶頸才比較有可能會落到是電腦主機上的網路介面卡，不然一般瓶頸會是 Internet 頻寬居多。

聰明的網站會使用大量的「字」搭配少量的「圖」來獲取利潤，原因是「頻寬就是錢」，若使客戶多吃頻寬卻沒有得到相對營收，對於網站會相當不利。什麼東西最吃頻寬？答案就是「多媒體資料」（圖、音樂、影片），最不吃頻寬的算是「純文字」，可是又不能都沒有圖，那會影響到美觀，所以在稍後會介紹到「多媒體資料」與「頻寬」該如何處理會比較有效能。

Note：頻寬購不夠用通常優先思考 Internet 部份，接著才考慮主機介面卡的部份。

高可用度

網站系統在上線一陣子以後，對於企業與個人的重要度相對提昇不少，此時若遇到一些亂流，像是流量爆增、主機硬體故障等等，難保系統能夠持續正常運作，接下來就必須思考那些軟、硬體設備會是比較有機會故障，導致網站系統無法運作，步步修正來保持您的網站高度可用性。

維持高可用度所花費的金額可大可小，老話一句就是：「錢要花在刀口上」，狀況的發生也有機率上的問題， 預設會先解決機率高的事件，例如：硬碟故障的機率會高於主機電源供應器故障，所以會先考慮採用 RAID 磁碟來防止因為單一磁碟故障而造成的損失。

進階學習：實現高可用度能夠被拿來討論的議題相當多，重要的是要適合您的需求。

Tips：提高可用度的一些解決方案大多數能夠順便提高效能，但是有些方案（少數）反而會降低一些些效能，這些效能上的犧牲通常都是為了成為一個「無懈可擊」的系統。

系統安全

只要網站暴露在 Internet 上，就要多加提防資訊安全問題，一般來說防火牆這類的機制通常是少不了的，使用作業系統內建或是外掛的防火牆設備都有可能，進階一層的安全保護像是入侵偵測防禦系統（IDS/IDP/IPS），這一類的資訊安全設備對於效能檢測來說，設備本身（防火牆與入侵偵測防禦系統）運作是否正常、是否過度忙碌，皆有可能影響到整體網站系統的效能。

Tips：資安設備的 Throughput（I/O 吞吐量）有可能會影響到整體效能。

Note：IDS 是 Intrusion Detection System 簡寫；IDP 是 Intrusion Detection and Prevention 簡寫；IPS 是 Intrusion Prevention System 簡寫，三者皆與入侵偵測與入侵防禦系統相關。

在正式上線後

會出狀況往往出現在正式上線後，例如：程式反應過慢、頻寬不足、伺服器當機與程式功能故障無法使用等等，這就好比一家新開張的餐廳，因為大量客戶湧入而造成的手忙腳亂。唯有計劃性的對應，才不至於弄的一團糟。

若是以為一昧的砸錢來更新硬體加快程式速度，或是像無頭蒼蠅的修改軟體就以為能夠解決問題，不只費時、費力與浪費金錢，運氣好的可能碰巧解決問題，運氣不好還有可能造成更大的問題，唯有正確找出效能瓶頸，才能有效的來解決問題。但通常效能調校問題的複雜度與困難度會伴隨著應用系統越大、相關設備越多與架構越大而更不容易處理。接下來先從單一電腦來談，系統效能的瓶頸經常出現在那裡。

Tips：別讓今天的解決方案，成為明天問題的來源。

找出效能瓶頸-先從單機效能談起

相對於叢集系統來說，要找出單機服務的效能瓶頸，感覺上比較簡單，解決的方式也較簡單，硬體部份就是換掉低速硬體，改用高速配備，軟體部份就是找出效能消耗最多在那裡，修改相關程式以減輕負擔。通常我們在針對硬體部份的觀察不外乎 CPU 運算能力、記憶體大小與 I/O 能力，分別詳述如下：

Tips：除非是當作繪圖工作站，不然顯示卡很難成為伺服器主機系統瓶頸。除了繪圖工作站外，另一個需要大量圖形運算的應該是３Ｄ類型的電腦遊戲，所以顯示卡效能好不好就會影響到３Ｄ遊戲執行。

記憶體大小

單台主機最常擴充的算是「記憶體」，當主機運作的行程一多，造成實體記憶體不足時，就會使用到硬碟上的「虛擬記憶體」，這樣一來會使得主機整體效能下降很多，因為「實體記憶體」（主記憶體）與「虛擬記憶體」（硬碟）兩者在存取效率上差別實在太大，而且若過度頻繁使用虛擬記憶體（也就是硬碟）拿來 I/O 的話，也會損耗硬碟壽命，反而得不償失。

主記憶體速度到底比硬碟快多少呢？以現今常見最普通的 DDR 記憶體來說，單條 I/O 最慢的都可達 1.6 GB/s（PC1600 DDR-SDRAM），若是支援雙通道的主機則更快；反觀硬碟，SATA 介面 I/O 數值為 150 MB/s，若以單顆 SATA 硬碟實際值大約 60 MB/s ，差別真的很大，所以若是發現電腦有記憶體不足的現象，擴充記憶體是不錯的選擇。

在 Linux 中，可使用指令「top」來觀察所有的行程，接著按下大寫的「M」可以依照使用記憶體的多寡來排序，另外可使用指令「free」來觀看實體記憶體與虛擬記憶體的使用情形，其中 Swap 就是 Linux 的虛擬記憶體，所以只要 Swap 沒有被 used（使用）過多或是過於頻繁，就還不需增加實體記憶體，如果已經擴充實體記憶體到硬體最大負荷量卻還是一定要用到很多的虛擬記憶體時，一般處理方式會換更高級的主機，如果不能換機並且記憶體已經擴充到極限了卻還是使用到不少的 Swap 時，建議將 Swap 磁區移到比較快的磁碟或分散在各個較快的磁碟，這樣這台主機的整體效能會比較好些。

圖為執行「top」指令並按下大寫「M」後的快照（依照記憶體用量來排序）

「free」指令的執行畫面

一台主機最多能夠使用多少的記憶體除了與主機板規格息息相關之外，還與 CPU 本身的定址能力有關，３２位元 CPU 的理論值達４ＧＢ（２的３２次方）；而６４位元可輕鬆超過４ＧＢ，實際值為２的６４次方（單位是 Byte）。６４位元 CPU 通常不向下相容３２位元，例如：PowerPC、UltraSPARC 與 Itanium，除了從３２位元演進的 x86-64 CPU 例外（AMD64 與 Intel EM64），才有向下相容於３２位元。使用６４位元 CPU 除了運算快速之外，另一項優勢就是支援超大記憶體。

Note：Intel 的 Itanium 有做到向下相容３２位元，只是效能與直接６４位元運作相差很多，避免在 Itanium 跑３２位元的程式會比較好。

Tips：現今常見的３２位元 CPU 皆擁有 PAE（Physical Address Extension）技術，使得這些 CPU 能夠控制的記憶體數量加大到６４ＧＢ（２的３６次方），但是這需要 CPU、主機板與作業系統皆支援才行，早期這種主機板與其搭配的記憶體通常價格不菲，到了現今不如直接換成 AMD64 或 Intel EM64 主機來的划算與便宜。

CPU 運算能力

CPU 運算能力通常也是效能瓶頸之一，尤其是在早期 CPU 時脈較低時（１GHz 以下），以現今動輒３GHz 的 CPU 運算能力來看，若要使得 CPU 非常忙碌，一般需要同時間有許多「行程」（Process）「正在運算」（Running），或是執行有些程式的動作也是比較耗用 CPU 運算，列舉如下：

依照著名的「摩爾定律」，CPU 電晶體數量會每兩年增加一倍，這意味著兩年前頂級機種的 CPU 運算能力，說不一定會比現在普通機種還慢，筆者就實際發生「雙 PIII CPU 時脈１GHz 效能比不上單 P4 CPU 時脈２GHz」的經驗，所以說挑選一個最符合自身價格效能比的機種，反而比追求頂級機種而來的重要，當然這要與當事者溝通，若初期不是購買高階機種，但卻需要跑大型程式或資料量會成長快速時，就要有未來換機的心理準備。

在 Linux 使用「top」指令可以很清楚的看出系統忙不忙碌，從最上方的開機多久了（Uptime）、線上共有幾個使用者、以及平均負載（load average）分別是１分鐘內、５分鐘內及１５分鐘內的負載。

Tips：平均負載的數字其實只是個粗略含糊數值，對於早期老舊的電腦也許３或５就會覺得慢到不行；但對於現在新的電腦來說，數值達到１０可能用起來也不覺得緩慢。

接下來是總共有多少行程（Process/Tasks）、幾個行程正在執行（running）、休息（sleeping）、停住靜止不動（stopped）及殭屍行程（zombie）。

Tips：殭屍行程（zombie）通常殺不死（Linux 使用 kill 指令來『殺』行程）也終止不了，最麻煩的是這種殭屍行程所佔用的記憶體只能透過重開機來釋放。

另外有兩個用來觀察行程的好用工具「ps」與「pstree」，相關的快照與指令分別列於 vmstat 圖檔下方提供參考。

繼續觀看 top 的資訊，接著是 CPU 忙碌情形，可按下 1234 的「１」來觀察多顆 CPU 的運作狀態，另外 CPU 使用情形百分比 us, sy, ni, id, wa 意思分別列於下表：

圖為執行「top」指令後，按下「１」顯示多 CPU 的情形。

由此可了解 CPU 的運算會被耗用在那部份，像是「應用程式」、「核心程式」或「等待 I/O」等等，這樣子就會比較了解瓶頸在那裡？另外有個指令「vmstat」也可以觀察 CPU、I/O 與記憶體情形，下圖為執行「vmstat 2」（每兩秒）的狀態，最後需按下「 Ctrl+c 」中斷。

「 ps 」指令經常搭配的參數像是「 aux 」、「 ax 」及「 -ef 」，參數差異主要是欄位上的變化；另外「 pstree 」指令可清楚看出行程之間的『父子』關係，「 pstree 」的「 -p 」參數可順道顯示出 Process ID，下圖分別為執行「ps ax」、「ps aux」及「ps -ef」與「pstree -p」的快照。

pstree 執行情形

藉由觀察系統運作情形，進而了解那幾隻程式比較吃資源或是有問題，看是要改寫程式以增進效能，還是更新硬體來補充效能，也可能應用叢集來解決重大負載，選擇一個價格效能比最好的處理方式。

Tips：此處所說的「價格」包含人力、物力及後續維護費用。

磁碟 I/O 能力

考驗磁碟 I/O 能力，最明顯的就是當作「檔案伺服器」。從早期 IDE（低階）或 SCSI（高階）硬碟，到異軍突起的 SATA 硬碟，若是以單顆硬碟的 I/O 能力來看，最主要的區隔算是「磁碟轉速」，撇開其他因素（例如：快取、I/O 介面、總容量）不談，選擇「高轉速」硬碟準沒錯（通常也比較貴），現階段 7200 轉 SATA 或是 10000 轉 SCSI 算是比較平價的選擇。

單顆硬碟有其 I/O 能力的極限，以一顆 7200 轉的 SATA 硬碟來說，實際值大約 60 MB/s 的表現算是很不錯，若是想要更高速的磁碟 I/O 能力，就要使用「團結力量大」的方式，也就是同時使用多顆硬碟來分散傳輸的資料，磁碟陣列是不錯的選擇，以主機板晶片上內建的 SATA RAID 來說，兩顆 SATA 硬碟作 RAID 0 應該可以再加速到 110 MB/s 左右，別懷疑！這只是一個簡單便宜的方案喔。

市面上還有許多大儲存設備的解決方案，通常超大儲存空間必須伴隨著高資料 I/O 能力，就好比台北 101 大樓不會只有一、兩部電梯來解決進出人口流量問題，相對的磁碟空間一大，資料的 I/O 能力必須要更快速，除了 IDE、SATA 與 SCSI 介面外，別忘了還有 iSCSI 與 Fibre Channel 這些高速解決方案，搭配 SAN（Storage Area Network）架構會在應用方面會更加的有彈性與擴充性。

Tips：便宜的 AoE（ATA Over Ethernet）也是 SAN 的解決方案喔。

在 Web-Based 程式中，較需要高效能磁碟 I/O 系統主要有兩個，一個是「資料庫的資料區」，另一個是透過 Web 來「檔案存取」部份（圖檔、音樂檔、影片檔與一般文檔）；使用高效能磁碟使得資料庫程式運算更順暢、更不會浪費時間在等待磁碟 I/O，而多媒體檔案的存取，就像檔案伺服器一樣，需面臨多人、多工大量同時存取不同資料的壓力。

在 Linux 下使用指令「hdparm -t 裝置檔案」可測試一下磁碟 I/O 的性能如何，另外指令「vmstat -p 磁區」可觀察磁區 I/O 的情況，若是能親自站在主機面前，不妨看看硬碟燈號，是不是閃爍得很嚴重。「磁碟控制」的能力對於 Linux 算是強項，例如：日誌型檔案系統（Ext3 與 ReiserFS）、軟體（Soft）RAID、LVM 到 iSCSI 與 SAN 解決方案，若要拿 Linux 來作高階應用，會是很不錯的選擇。

進階學習：用 Linux 作檔案伺服器（NFS 與 Samba），在 Disk 或 File I/O 效能上，可算是用過的人都說好。

Tips：現階段的磁碟 I/O 速度若以行車速度來比喻，單顆磁碟就像摩托車每小時 60 公里、兩顆 SATA 做 RAID 0 就像汽車每小時 100 公里，iSCSI、U320 SCSI、Fibre Channel 就分別像自強號火車、高鐵列車與噴射客機，高速設備的造價絕對是呈現等比級數成長，在電腦應用來說，我們追求的是「適合」的配備，但不見得是「最快」的配備。

指令「 hdparm 」與「 vmstat 」執行情形。

網路 I/O 能力

當磁碟 I/O 能力加強後，能夠將資料快速的送往 CPU 作運算，另一部份資料很有可能就是透過網路傳輸出去，當作伺服器的主機，往往面臨大量客戶端來要求檔案傳輸，所以網路 I/O 能力就會顯得重要，以現今最普通的 10/100 Mbps 網路介面與交換機來說，理論值可達 12.5 MB/s，扣除網路封包、框架的必要資訊損耗，實際值可達 11 MB/s 左右，但這對於我們現在的單顆磁碟 I/O（大約 60 MB/s）來說，算是慢的，若程式會傳輸大量資料在網路上，換成 Gigabit Ethernet 會是便宜大碗的選擇。

當主機介面換上高速的 Gigabit Ethernet 後，除了主機本身磁碟 I/O 能力要夠外，還須注意到客戶端到伺服器一路上是否都一路順暢，中間只要有一個介面是 10/100 Mbps 就無法完全發揮 Gigabit 效能。

若以筆記型電腦為例，換上 Gigabit Ethernet 後，瓶頸會是在磁碟 I/O，因為筆記型電腦的硬碟轉速通常比桌上型電腦低，所以筆記型電腦的磁碟 I/O 能力（大約 30 MB/s）也比桌上型電腦差，這也是筆記型電腦在跑美工繪圖（尤其是大圖）時，會不夠力的原因。

Gigabit Ethernet 傳輸的理論值 125 MB/s，扣除一些損耗可達 110 MB/s 左右，這個 I/O 能力對於 Web-Based 應用程式可說是綽綽有餘，如果 I/O 飆高到這樣程度，Internet 傳輸的話頻寬費用應該也不少，所以超級大量的磁碟 I/O 反而是應用在 Intranet 機會比較多。Gigabit Ethernet 對於一般中、小企業（包括網咖）來說，現階段算是很夠用，若發現單台主機真的 I/O 太大，還可透過 Cisco EtherChannel 或 Linux Bonding 技術，將兩個以上的 Gigabit Ethernet 串在一起（２Gbps 以上）來傳輸，不然換光纖設備（２Gbps /４Gbps 或更高）也行。

在 Linux 可藉由指令「ifconfig」與「netstat」來觀察網路介面封包 I/O 與連線情形，新一代 Linux 建議使用指令「ip」來控制。若想要看比較漂亮的圖表，可使用 MRTG（Multi Router Traffic Grapher）透過 SNMP（Simple Network Management Protocol）來抓取主機網路 I/O 資訊並繪製成圖表。Linux 對於 10/100/1000 Mbps 與全雙工、半雙工的觀察與控制，早期使用指令「mii-tool」來控制，到了 Gigabit Ethernet 則建議使用「ethtool」，底下分別介紹這些指令基本的使用方法。

進階學習：SNMP 除了提供網路資訊外，還可以提供 CPU、記憶體、行程這些資訊，並且 MRTG 也可以配合繪製成圖表，只是通常我們只用到觀察網路介面而已。

ifconfig 指令主要觀察 RX（收）/ TX（送）的 Packets（封包）與 Bytes（位元組數），另外「errors:0 dropped:0 overruns:0 carrier:0」沒意外的話都會是０，除非硬體（網路卡或網路設備）出狀況，才會不為０，至於 collisions:0（碰撞）只會發生在 Hub（集線器），現在通常使用 Switch（交換器）所以沒意外的話也是０。

下圖為執行指令「netstat -na」的情形，主要分成上下半部，上半部是 TCP/IP（也就是 Internet connections 的部份）連線情形，下半部是 UNIX domain sockets（本地主機 Socket File 連線），由 TCP/IP 部份可看出的資訊包括：tcp 或 udp 連線、傳送與接收量、本地與遠端主機所使用的 IP 及埠號，最後一個欄位是連線的狀態，由這些資訊可觀察對外連線數量多寡。

執行「ip -s link」指令的資訊與 ifconfig 類似，故不再贅述。

下圖為執行「mii-tool」、「ethtool」指令的快照，可發現這台主機有 Gigabit 的能力但卻銜接到只能提供 100 Mbps 的網路設備，這兩個指令也能用來調整網路卡的一些參數。

快照自義守大學 ftp 站台 URL 為 http://ftp.isu.edu.tw/mrtg/ 的流量統計圖表，他們應該也是應用 mrtg 來提供相關資訊。

匯流排與介面卡 I/O 能力

另一個單機效能瓶頸還有「匯流排速度」與「介面卡」，以早期 CPU 時脈還在１GHz以下的眼光來看，在當時的匯流排速度與搭配 PCI 介面會覺得還算過得去；但是以現在硬體配備的 I/O 能力來看，PCI 介面就只適合低速設備了，若要使用高速設備，像是 Fibre Channel 介面卡、高速磁碟陣列（RAID）卡，就必須用上較新、較快的介面，像是 PCI-X 與 PCI Express（PCIe）。

Tips:在此並未詳述這些規格的速度，有興趣請參考網址：http://en.wikipedia.org/wiki/List_of_device_bandwidths 有一些常見的設備速度列表，比較需要注意到的是，PCI Express、SATA 是採用 8B/10B 編碼方式傳輸，所以在換算 Byte/Bit 時要除以 10 而不是我們一般除以 8 的方式，這也就是有人說 SATA 介面速度為 1.5 Gb/s 或 150 MB/s 的原因，其實兩個數值對 SATA 來說是一樣的（以 SATA 一代為例）。

多台電腦的解決方案

能只使用單獨一台伺服器解決一整個應用系統的，要是我就不會用兩台以上，因為單台主機要比多台主機容易控管多了，這也是只用一台主機的最大好處。但有時系統過於龐大、負載過重而且預算卻有限下，則必須使用多台或叢集電腦方式來服務，使用多台主機優點在於高價格效能比、高擴充性與 HA（High Availability，高可用度），在享用「團結力量大」的多台主機系統優點時，則請盡量避免多台主機的缺點「單點故障」，好好監控您的叢集系統吧！

要從單獨一台主機變成多台主機方式，理念上來說就是「工作（服務）切割」與「叢集架構」。

Tips：多台主機的單點故障問題，就好比磁碟陣列壞了一顆硬碟一樣，磁碟陣列使用多顆硬碟來提供高可用度後，通常廠商都會附監控程式來觀察是否有故障的硬碟，因為多顆硬碟壞掉一顆的機會實在比只有一顆硬碟壞的機率高的太多了。

資料庫獨立運行

要從單一主機分成多台系統，最簡便的方式就是去分離（切割）電腦的工作（服務），使得主機各司其職，就好像員工在大型企業上班一樣，自己做自己分內的事情。以 Web-Based 程式系統來說，將「資料庫」與「Web 伺服器」分開成兩台以上還蠻常見的，如此一來就把 Web-Based 應用程式最主要的兩大負載『Web-Based 程式運算』與『資料庫搜尋與讀寫』一分為二。

這樣子的架構對於硬體需求部份有著立竿見影的效果，以長遠看來整體架構費用就會比較便宜，理論上此舉能夠負擔更多同時上線的客戶量是毋庸置疑的。硬體變化的部份像是 Web Server 的硬碟不妨使用 SATA 就夠用了，而資料庫則需加強 CPU 運算能力以及磁碟 I/O 效能，這樣才可以趕快把客戶端要求回應回去，。

下表為一個簡單的範例，有著為未來更高的負載而作的準備與擴充性：

「儲存設備」獨立

在上述架構中，關於磁碟空間需求主要考量「非純文字」檔案的增加量而定，反而不是 Web 程式檔（資料量很小）或是資料庫的資料（成長幅度較平緩），其實「非純文字檔案」才是消耗磁碟空間與記憶體的殺手，這些成長幅度較大的資料格式，舉例來說像 Blog、相簿與拍賣上傳的照片（大圖與縮圖）、透過 Web 傳輸的音樂檔與影片檔（Media 伺服器）與 Web-Based 檔案伺服器所儲存的文件檔（pdf、Office 文件檔與所有的二進位檔），這些檔案的傳輸對於頻寬與主機能耐都是考驗。

在 Web 主機與資料庫主機分離後，另一個改善架構的方式就是將「儲存設備」獨立，也就是將「非純文字」資料，存放在特定的儲存設備。以 Web-Based 程式來說，這一類的資料，在還沒分離之前，通常是與 Web 伺服器放在一起，所以 Web 伺服器磁碟就變得要好一點的 SCSI，分開後變成 DAS（Direct Attach Storage）架構，而將 SCSI 磁碟改用 SATA 磁碟陣列是因為 SATA 硬碟磁區空間大且價格低，效能上也許沒有像高階 SCSI 那麼好，但也還應該算夠用。

Web 叢集

若 Web 負載更大後，會使用 Web 叢集，此時會將 DAS 架構改換成 NAS（Network Attach Storage）架構以順應 Web 叢集，通常 Web 叢集架構成這樣已經算是中大型架構，但 NAS 效能會侷限在本身 File-Level Access 的關係，若是想要更多叢集節點與更快 I/O 則必須應用上 SAN 架構搭配 Cluster File System（叢集檔案系統）。

Tips：通常 Block-Level I/O 會比 File-Level Access 擁有較佳效能。

SAN 架構

SAN 是現階段最優秀的儲存架構，在 SAN 作叢集就必須使用 Cluster File System，因為 SAN 存取資料採用 Block-Level I/O 方式，效能上會比 NAS 使用 NFS/CIFS 更好，一般來說 Web 叢集若機器台數不多 I/O 的量不大，使用 NAS 等級架構就足夠。近一、兩年（2005-2006）Linux 兩大巨頭廠商不約而同提出 SAN 解決方案，包含 iSCSI 與 Fibre Channel 並配合 Cluster file System，RedHat 提供「GFS」（Global File System）而 Novell SuSE 搭配資料庫大廠 Oracle 合作使用「OCFS2」（Oracle Cluster File System Version 2），可預期 SAN 的市場會越來越大、越來越平民化。

資料庫叢集

當 Web 叢集化後，由 Web 叢集主機所大量發出的資料庫查詢與寫入，使得單獨一台資料庫處理資料的速度就顯得力不從心，此時通常會將資料庫也改成叢集架構，其中最簡便、同時也是花費最少的作法就是利用資料庫提供的 Replication 功能，產生多台可提供 Web 叢集查詢的資料庫主機，用以分散負載，除了使用 Replication 外，各家資料庫通常會提供自家專屬的 Database Cluster 完整解決方案，通常需要廠商專業人員協助，費用較高、也較有保障，例如：MySQL Cluster、MS SQL Server、Oracle RAC 與 IBM DB2 等等。

各家資料庫 Replication 方式大同小異，架構上大致分成兩種：「Single-Master」與「Multi-Master」方式的 Replication ，比較表如下：

Tips：將帳號/密碼統一管理提供單一簽入（Single Sign-On）認證系統，像是「LDAP」、Unix 用的「NIS」與微軟主推的「AD」（Active Directory）都有類似 Replication 的技術在裡面。

Note：DNS（Domain Name System）將 Master 傳輸資料給 Slave 的動作，稱為「Zone Transfer」，也是類似 Replication 的表現。

資料庫叢集配合 SAN 架構

在資料庫使用 Replication 之後，另一個大問題就是資料庫資料會伴隨叢集主機節點增加而呈現倍數成長，所需磁碟就會越來越多而造成浪費，以一組六個節點的資料庫叢集來舉例，每增加 2GB 的資料庫資料，就需使用共 12GB 磁碟空間來服務而形成浪費，此時若能夠使叢集資料庫『共用』一份，也就是使用 SAN 架構，將資料庫資料放在 SAN Storage 並且資料庫本身能配合運作，這樣不只節省磁碟空間，並使得每一台主機都是 Master，此時不需再做 Replication，因為資料庫本身已經處理掉資料同步的問題，此架構最負盛名的就是 Oracle RAC（Real Application Cluster），另一優點他可以避免 Multi-Master Replication 在資料同步能力方面的問題。

進階學習：要做到以上方式需使用 SAN 架構，並且資料庫軟體也能夠配合。

Tips：Novell SuSE 與 RedHat 不約而同的與 Oracle 合作，配合 SAN 架構來推廣『無懈可擊』資料庫。

Proxy 伺服器

另一項改善 Web-Based 效能的利器就是架設 Proxy 伺服器，這裡談到的 Proxy 伺服器是「反向」（Reverse）Proxy 伺服器，不同於一般常見的 Proxy 伺服器，這個 Reverse Proxy 在 Web-Based 架構中通常是架在『最前線』，最前線也就是 Client 端從 DNS 查詢到的 Public IP 主機，在這樣架構下就只有 Reverse Proxy 才能夠向後端「真正的」 Web 伺服器要求資料。

通常架設 Reverse Proxy 伺服器最主要的優點就是『Cache』（快取），次要的好處才是『安全』，可以多一層保護 Web 伺服器。『Cache』效益真的很大，尤其對於重複、相同 Web Request（要求）特別有用，例如瀏覽相同一張照片、查詢同一個關鍵字等等，採用 Reverse Proxy 伺服器能夠使得 Web 主機與資料庫主機都少忙些，另外 Reverse Proxy 伺服器當然也可以叢集化。

Reverse Proxy 伺服器相關的軟體在 Unix 最知名的當屬 Squid，另外 Apache 也可以成為 Reverse Proxy 伺服器；在微軟則通常使用 ISA（Internet Security and Acceleration）Server。

負載平衡方式與設備

當主機叢集化後，必定會面對到如何負載平衡的問題，負載平衡的方式眾多，像是使用「DNS」、「Layer 4 switch/router 設備」、「LVS（Linux Virtual Server）」與「Reverse Proxy」等等，運算的方法也有多種，像是「Round robin」、「找比較不忙的主機」、「找反應比較快的主機」與「找比較近的主機」等等，筆者底下舉出二個例子提供參考。

例一：使用「Linux Virtual Server」，通常這種方式會有 Virtual Server 與 Real Server 架構，首當其衝的主機角色像是導演（Director），會指導流量到不同的 Real Server 上，若要更安全的架構，前線的導引主機亦可採用 Active-Backup 架構，使得任何一個節點故障都不會造成服務停擺，另外 monitor（監控）後面 Real Server 健康也是很重要的。

Tips：Layer 4 router 設備的運作方式與 LVS 非常類似，也有 Real Server 與 Virtual Server 架構。

畫面快照自 LVS 的網站，網址 http://www.linuxvirtualserver.org/whatis.html 由圖可清楚的看出 LVS 架構。

例二：使用「DNS」搭配「Round robin」，這種方式在 DNS 的 A Record 指向到多個 IP，Client 端主機就會選擇其一來存取，達到流量分散/負載平衡的功能，這個方式算是比較簡單，但比較大的缺點就是單點主機故障，會導致服務中斷問題，若需求是偏向高可用度，建議使用「例一」架構會比較好。

DNS 設定紀錄範例如下：

www   IN    A    2.2.2.2www   IN    A    2.2.2.3www   IN    A    2.2.2.4

Web 程式與資料庫效能調校及優化

這裡主要是程式面來調整效能，像是檢查並改善效率差的 SQL query（查詢），資料表該做索引的就一定要做出來，搜尋時就盡量依照索引欄位來找，不要動不動就把資料表從頭掃到尾的浪費運算資源等等；Web 程式部份則一定要裝上 Cache，例如 PHP 的 Zend Optimizer 優化，能使用前端 Web 程式就運算處理掉的就不要丟給後端資料庫來算，有一些隨機出現的資料，不一定要常常重複執行運算，採用一陣子運算一次也可以。關於「隨機」功能，主要是能夠實際做出來即可（也就是看起來像是隨機），但卻不一定要把所有的資料拿進去「隨機」，減少無謂的 CPU 運算消耗。

Tips：把程式調的有效率一點，就可以多省一點硬體的費用。

圖文分離

有些網站站台會將圖片與文字所使用的主機與 Internet 線路各自獨立開來，通常這樣的做法有兩個情況﹔一個情況是圖片快慢與網站服務不是有很大的關係，為了避免傳輸圖片造成網站緩慢，所以獨立開存放與傳輸圖片的網站主機，使得傳輸文字的部分不會受到影響，會使客戶有錯覺網站還蠻快的（因為文字都會先出來），圖片在隨後到齊即可。

另外一種情形則恰巧相反，圖片反而是這類型網站的重點，例如：相簿網站，相簿網站反而要讓圖片快速傳輸才是，會將圖文分離的原因通常是為了將帳戶資料分散，這類型的資料分散與負載平衡與我們之前探討的方式不太一樣，這種方式是由 Web-Based 程式來作流量分散的，也就是一群用戶共用一台，另一群用戶共用另一台的方式，至於群組的劃分，看是要使用編號或是帳號字母來分都可以，這種分流的方式還蠻常見的，至於缺點呢？應該算是磁碟空間的浪費，原因是這樣子的分散架構會成一台一台個別使用 DAS 方式的主機，或是一群組、一群組的幾台 Web 伺服器 + NAS 伺服器，很不容易確保磁碟使用率均衡，而且想要搬移用戶資料到別的群組機台時，並不是那麼的方便。

群集電腦系統監控

當系統已經叢集化後，監控每一台電腦與網路設備的工作相形重要，因為客戶大多遇到服務「有些」或「部份」的功能無法（或不堪）使用了，才會反應給提供服務的廠商，若由客戶反應系統故障才處理算是比較慢且比較被動的方式。通常一個營收狀況不錯、高效率的網站服務，會採用比較主動方式，調整成由『電腦去監控電腦』的模式，遇到出了狀況，則發通知給管理人員，藉由透過『e-Mail』、『手機簡訊』或『即時通訊』都是蠻不錯的通知方式。

Note：有些網站會採用輪班方式來負責處理機器異常，其實就像製造業看守機台類似。

結語

一個成功、高營收的 Web-Based 網站程式系統，筆者都戲稱為『超大型的自動販賣機』，與小型自動販賣機不同的是，一個是銷售出去的貨品不同，另一個就是網路「無遠弗屆」的特性；貨品能夠是無形的「廣告與企業形象」、「知識或資訊」、「軟體與數位資料」、「心靈上的歡愉」到有形的「百貨用品」，通通都可以拿到網站上來銷售，要說什麼東西比較類似網站的，應該算是電視台吧！

電視台與網站站台除了放送距離與媒介不同外，最大差異在於「互動性」，電視台互動需要靠其他媒介（例如：電話 Call in），而網站的互動則是要靠「程式」與「介面」密切配合，程式運行的順不順暢就是效能問題了，整體網站給人的觀點好壞，「效能」算的上是一大因素，連帶著效能調整就顯得格外重要，談到這些大型網站為何不約而同的使用 Linux 搭配其上的應用程式軟體，答案十分簡單，就是出在價格效能比的優勢。

效能的調校需要細心的觀察、慢慢思考問題出在那裡，以及身體力行的實做，對於一些設備或規格，其實並不一定要詳細記憶他的數值，用到時查的到即可，經驗也是很重要，也許慢慢的您會想出更好、更妙的解決方案，來處理遇到的瓶頸，尤其對於 Linux 這種可以深入客制化的系統，相信您會『玩』的更好、更能夠針對問題的重點來解決。

在本文的最後，來欣賞一下知名網站維基百科 http://en.wikipedia.org/ 他們的叢集架構情況。

Tips：維基百科中文站台網址 http://zh.wikipedia.org/，下圖快照自 http://zh.wikipedia.org/wiki/Image:Wikimedia-servers-2005-04-12.png