下文摘選「網站效能調校實戰經驗大募集」實戰專家與獲獎邦友分享的技巧與經驗。

實戰專家 王建興:
網站應用程式已經是最常見到的應用程式型態之一,它效能特性和傳統獨立執行的應用系統,或是主從式架構的系統不同,也因此要調整它的效能,自然也有獨特之處。

無論我們想要調整效能的應用程式類型是什麼,都必須考量系統是否具備夠好的延展性,也就是說,當系統的負載提高時,是否可以透過投入更多的資源(例如主機、頻寬),使得系統依舊能夠提供足夠品質的服務。

許多網站在初期開發時,並不會立即面臨到高流量的挑戰,因此不需要在初期投入過多的資源(例如主機的設備)。但是在一開始,如果能設計一個具延展性的架構,日後即可藉由資源投入,也能提升系統整體的效能表現。


目前許多瀏覽器都提供了工具或外掛,可以讓開發人員檢視網頁元件下載所耗用的時間,藉此找出效能瓶頸所在,再加以調整、優化。



利用叢集增加負載平衡與容錯能力
在架構上,許多網站都採用叢集(Cluster)的方式,允許將多個Web應用程式伺服器組織起來,共同對外提供服務。除了可以達到負載平衡的功用之外,也能提供容錯的機制。

在網站營運的初期,也許只需要一、兩臺網站應用程式伺服器,但利用叢集架構,可以在日後流量增加後,擴充更多的網站應用程式伺服器來提供一樣品質的服務。

想要導入負載平衡機制,可以在Web應用程式伺服器前端,選用適當的負載平衡軟硬體產品。最簡單的方式,可以只利用免費的Apache HTTP伺服器,置放在Web應用程式伺服器前端,就能利用它來達到負載平衡的效益。

除了利用具延展性的架構之外,網站所用到的各式伺服器,例如HTTP伺服器、應用程式伺服器,以及資料庫伺服器等,它們組態設定也會深深影響到系統的效能。

例如HTTP伺服器及網站伺服器的Thread Pool或Process Pool的設定值,會影響到同時可連線的最大上限。設定值過小,同時間能提供的連線數便少;設定值過大,有可能耗費系統資源,甚至因為資源競爭過度,反而造成效能低落。

同樣的,像資料庫伺服器的同時連線數、快取大小等參數,也都會影響到應用程式的效能。因此應該針對伺服器的可用參數,找出最適合的設定值。

以Firebug檢視頻寬耗用情形
頻寬往往是網站最珍貴的資源。相較於伺服器主機硬體以及儲存裝置,頻寬資源受到的限制更多,這也使得網站對外的頻寬輸出,成了網站效能重要瓶頸之一。

利用效能量測工具檢測網站,如果發現瓶頸發生在對外的頻寬輸出,就必須朝降低網站主機消耗對外頻寬的方向著手。

首先要做的功課是審視網站對外輸出檔案的大小,這直接影響到網站對外消耗的流量。要了解瀏覽器所送出請求,以及取得回應的細節資訊,可以安裝像是Firebug(FireFox的外掛程式)這類的網站偵錯的工具。透過分析HTTP請求、回應的過程,可以知道個人端在瀏覽你網站的網頁時,同時間會發出多少個請求,而每個請求所取得的檔案內容究竟有多大。


由Yahoo!推出的Firebug外掛YSlow,從13個面向為網頁診斷效能,它除了指出瓶頸所在,也提供改善的方法。



減少網站耗用頻寬所常犯的錯誤
有許多網站使用精美的圖檔,但沒有適當壓縮,是常見的耗用頻寬錯誤。倘若能降低所用的顏色數量,或採用較高的壓縮比,都能在些微降低視覺效果的情況下,大幅減少檔案處理量。

此外,現今有許多JavaScript程式庫,可以加快開發過程,提供豐富多變的視覺效果,提高使用者體驗。但是這些程式庫通常體積不小,而程式開發人員如果一不留意,將它們全部引用。如此一來,使用者必須下載完全不會派上用場的檔案,而且徒然耗費頻寬。

因此重新檢討所動用到的JavaScript是否必要,以及能否加以瘦身,也是十分必要的步驟。

對於很少變更的靜態檔案,我們可以善用瀏覽器端快取的機制,將它們設定為可快取的檔案,如此一來,在快取過期之前,都不會重新到伺服器上請求檔案內容,就能夠有效降低伺服器的頻寬消耗。

另一個常見的頻寬殺手,便是網頁程式所輸出的過長HTML。對於內容過長的HTML,可以設定應用程式伺服器在輸出時,加以壓縮,成為GZIP之類的格式,到了瀏覽器端後再由瀏覽器自動進行解壓縮。
常見的網站伺服器都有內建壓縮的功能,針對HTML類型的輸出,高達10倍、20倍的壓縮率也很常見的結果。

除了改善上述常見錯誤,針對靜態類型的檔案(例如圖片或影片),由於它們並不倚靠任何動態的邏輯去產生,所以沒有必要放在機房中,消耗那相較而言較昂貴的頻寬。

更好的作法是將這些檔案分流到虛擬主機,這些服務(尤其是在美國)的頻寬費用通常都很低廉。

有些ISP也提供Reverse Proxy的服務,更允許你將內容發布到他們所提供的Reverse Proxy之上,不僅能將網路流量的消耗導到Reverse Proxy端,透過它們自動取得主機上內容,更可以簡化發布的方式,同時頻寬的價格,十分的便宜。

能否改善資料庫存取,也是提升效能的重點
現今的網站,免不了要存取資料庫,而這個環結經常成為網站效能中最為低落的一環。要提升資料庫存取的效能,可以從改善資料庫Schema設計、改善SQL語法與善用資料庫快取著手。

設計資料庫時所廣泛採用的正規化技巧,倘若過度使用或錯用,便會造成存取資料時的效能低落(因為得透過跨資料庫表格的Join動作,才能取得所需的資料)。此外,未能建立適當的索引,同樣也會影響到存取時的效能。

開發者也有責任了解自己寫下的每條SQL述句,在不同的資料規模下,所需付出的效能成本。開發者必須知道哪些SQL述句,可能會付出昂貴成本,並且試著加以調整。大多數情況下,同樣的目的、換一種寫法,就會有不同的效能表現。

有時遇到不容易調整的情況,就必須回過頭尋求修改商業邏輯的方法。許多商業邏輯並非完全不可撼動,通常稍微犧牲商業邏輯的完美性,都能換取到一定的效能表現。

最後,想要提升資料庫效能,使用資料庫快取是一條快速的捷徑。例如許多大型網站都採用Memcached快取系統,做為資料庫快取伺服器,像Facebook甚至採用了超過兩百臺的Memcached主機。

盡量將資料庫中查詢得到的資料,置於資料庫快取伺服器上,可以節省重新查詢資料庫的動作以及資源耗費。由於資料庫查詢動作正是最慢的一個環節,因此資料庫快取對網站效能的提升,會有令人驚喜的效果。

作者簡介:
王建興
清華大學資訊工程系的博士研究生,研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人,專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同,從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。分離動、靜態網頁,讓伺服器做擅長的事

實戰王doggy(IT邦初學者9級):
在網站效能調校上,網站前端可採用Squid 建置Reverse Proxy Server,加速網站回應速度。這種做法也能擴大每一臺伺服器的網頁吞吐量(Throughput)。不過網站的程式也需要送出適當的 HTTP Cache Header,才能與Reverse Proxy Server充分搭配。

如果流量真的很大,可以架設多臺 Reverse Proxy Server分流,除了Squid之外,也可用Nginx Web Server來負載平衡。除了使用Reverse Proxy Server之外,也可以採用叢集架構架平衡負載,這類的商業產品很多,例如:F5、A10、Cisco等都有,不過免費的也不少,像是Linux Virtual Server。

分離靜態頁面與動態網頁
要達到較好的效能,主機也要講究專業分工,徹底分離「靜態頁面/檔案」與「動態網頁」,妥善運用主機資源(處理器、記憶體等),將個別主機負責的工作切割,可有效提高網頁吞吐量與運行時的效率。

首先將靜態網頁(圖檔、Flash、JavaScript、CSS等),集中在特定幾臺Web伺服器,這樣配置的主機資源利用率會更高,因為靜態頁面的處理器與記憶體的資源消耗率低,純粹消耗頻寬而已,用專屬或小型的Web伺服器(例如Nginx、 TUX Web Server、Boa Webserver等)去發送這些檔案,可節省不少記憶體,且運作的效率也會比 Apache、IIS這類多功能 Web Server的效率還高。

另外,可將動態網頁依照功能性與流量做水平分割或垂直分割。水平分割是指單一功能流量大,可採用負載平衡機制將主機負載分流,垂直分割是指依照單一服務拆分為多個子功能,每個功能配置獨立的主機專門提供此功能的相關資源運用與處理器運算。

重點在於,主機跟主機間、服務跟服務之間的關連性或耦合性如果越低,網站架構的延展性(Scalability)越高。因為大型網站最需要的就是延展性,好的延展性,能讓網站經營突破甜蜜點(Sweet Point)時,可從5臺主機順利擴充到50臺,而不用大幅修正網站架構與程式。

資料庫分割可以提升效能
關連式資料庫的規畫架構,在效能提升上也扮演重要地位。除了可以採用叢集架構架設資料庫主機外,流量很大時,同樣也可以採用資料庫的「水平分割」與「垂直分割」技巧。

水平分割只將一個資料庫中的表格,拆分在不同的資料庫主機中以分散資料量,降低資料庫伺服器負擔。

垂直分割就更複雜了,將「同一個表格的資料」拆分到不同資料庫伺服器中,這大概要到千萬流量才會用到這種架構。這時就必須規畫演算法,將資料拆分或資料搬移。

找出效能瓶頸點
要找出效能問題,就得對症下藥,分析出主機的效能瓶頸是出在 I/O 、處理器,或是記憶體出了問題。

如果出在I/O,可將部分I/O改用記憶體做快取,或是將檔案存取優化。若單一主機的I/O優化已經到了極限,可改採 NAS或SAN解決方案。

如果出在處理器,可檢查程式的寫法是否有改善的空間,或是因為網站的程式例外太多、或是垃圾回收(Garbage Collection) 執行過於頻繁所致,這些都會造成處理器瓶頸。

要是問題出在記憶體,就要檢視是否程式沒寫好,導致Memory Leak問題(最常見的情況)。如果無法再調校,只好再加記憶體。建議採用64位元的作業系統,對大量記憶體支援度較好。

認真獎haoming(IT邦初學者9級):
在Windows平臺優化Apache伺服器效能
我的Web伺服器架構是由4臺Windows Server 2003組成,第1、2臺用在Apache伺服器,第3、4臺伺服器在透過NAS存放資料,透過叢集架構,確保無論任何一臺故障時,仍然能正常運作。

另外,為了存取資料的順暢,我將4臺Web伺服器加入AD 網域中,可以避免透過NAS架構讀取資料時產生錯誤。也可以避免來自網域外的電腦不正常地存取資料。

第1、2臺伺服器上面之所以使用Apache的Web 伺服器,是為了執行PHP程式。而兩者則透過Microsoft的NLB建立負載平衡架構,也可以避免單點伺服器存取過量。

Apache在Windows下長時間執行,會有記憶體無法正常釋放的問題,造成PHP程式出現Memory Buffer錯誤的訊息。解決方法是在離峰時間讓不同的伺服器分別重新啟動。而因為有NLB與叢集架構搭配使用,基本上,使用者不會感受到伺服器中斷。

Apache在Windows下執行的時,不像在Linux底下有良好的搬移記錄檔的機制,目前在網路上找到的解決方法,長時間執行都會出現記憶體鎖定,沒有辦法正常釋放。

所以我寫一個批次檔,在重開機時將現在執行的log檔案複製、搬移。這樣可以避免伺服器上面的記錄檔暴增,避免主機停止服務。

另外,我也發現Apache在Windows下運作的時候,沒有辦法百分之百發揮到伺服器的硬體效能。例如記憶體有2GB的時候,往往執行到800MB~1GB時,Web伺服器就會明顯變慢。

這時候可以利用Apache的Reverse Proxy功能,做到第二層的軟體負載平衡,在伺服器上面建立多組的Apache Services,然後透過負載平衡的功能,分流給不同的Apache Session運作。

認真獎scottchen(IT邦初學者2級):
用3臺Web伺服器平衡負載
我提供一個實務上的網站架構,這麼做會有較好的效能表現。前端用1臺Layer 4 交換器,後面接3臺Web伺服器,之後再接資料庫。這個架構有下列的好處:

1.把網站的流量分散到3臺Web伺服器做負載平衡,可以處理的流量。

2.提供備援的功能,如果其中有1臺Web伺服器掛掉或要停機維修,並不會影響網站運作。

3.因為3臺Web伺服器互相備援,所以不需要做RAID,可以省下開銷。

4.保留擴充的彈性,如果未來網站流量增加,可以繼續在這個架構下增加Web伺服器。

5.因為採用Layer 4交換器,所以能藉此提供Session管理的機制。

另外網頁應用程式應該加入快取機制,避免資料庫存取太頻繁,造成效能瓶頸。

vincent118(IT邦初學者4級):
頻寬加倍,費用反降的做法
多年前公司的商業網站放在美國,當時租用4個機櫃空間,以及大約70MB的頻寬。由於每個月的費用將近100萬元,同時頻寬也不夠用,需考慮升級頻寬,但每個月粗估要150萬元,而且還不見得能達到需求。

當時正計畫將網站推展到其他地區,像歐洲、亞洲,但是評估後發現有些設備會重複投資,後續的維護成本更是超出預計。在預算有限的情況下,只好想想其他辦法。

公司網站是採多層架構,第一層是Web,第二層是應用程式伺服器--當時用的是Cold Fusion,後面才是資料庫。而資料流的組成中,FTP以70%占最多,其次是靜態網頁約占20%,而應用程式的流量僅約2%,其餘是送廣告郵件的流量。

最後想出的計畫是由一家ISP談其他地區的網站空間及頻寬,用來放靜態網頁及FTP的資料。同時負責透過F5的設備做到全球的負載平衡。

另外找了一家離公司比較近ISP,將應用程式伺服器的網站代管及頻寬,交由該家公司負責。

這樣建置方式,只有應用程式伺服器需自行準備硬體設備,因此機櫃從4個降至1個。其餘的設備都是透過租用,另外,頻寬也由70MB暴升到175MB,但總費用只要75萬元。從帳面上看,節省每月25萬元,但實際上還有人力費用5萬元,設備攤提約15萬元,維護約4.5萬元,以及多得的頻寬費用。

熱門新聞

Advertisement