登入  |  English
感謝您對「自由軟體鑄造場」的支持與愛護，十多年來「自由軟體鑄造場」受中央研究院支持，並在資訊科學研究所以及資訊科技創新研究中心執行，現已完成階段性的任務。 原網站預計持續維運至 2021年底，網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生（Shih-Chieh Ilya Li）。

Plone 效能測試綜合報告

建立日期 2006-11-26 08:00      最近更新在 2007-03-15 18:16 作者是 紀博文

◎ 前言

網站效率，一直是網站件置過程中首要被關注的議題。而由於 Plone 網站功能強大，且使用大量動態運算物件，因此在直接連線的情況下，整體效能可無法負荷大量存取。

然而為了因應此類的動態網站，此類動態網站多半會搭配快取機制。以大福提昇網站的運作效率。

這份測試報告的主要目的，在於測試並比較何種快取方案，能夠產生最大的效能提升，並對測試結果進行分析與建議。


 
◎ 測試環境

一、硬體

  • CPU：Intel Pentium iii Mobile-1.03G
  • RAM：640 MB
  • HDD：IBM 30G 4200 RPM
二、軟體
  • Ubuntu Linux 6.06
  • Kernel 2.6.15
  • Apache 2.0.55
  • Python 2.4.3
  • Zope 2.9.4
  • Plone 2.5
  • Ab 2.0.4
三、方法

每一次的測試開始前，均先重新啟動 Apache，以確保存在記憶體中的快取資料已被清除。

每項測試均統一使用 ab –n 500 –c 20 –d –k

  • -n 500：共執行 500 次連線測試
  • c 20：同時發出二十個請求
  • -d：不顯示百分比分佈表
  • -k：使用 HTTP-KeepAlive 連線
◎ 測試結果

一、Apache mod_proxy 的影響

(一) 說明
如果要搭配 Apache 作為 Zope 的前端伺服器，就需要使用 mod_proxy 模組。

過程中，資料先經過 Apache 向 Zope Server 提出請求，Zope 將資料回應給 Apache 後，Apache 再將資料傳回給瀏覽器。

本測試的目的，在於評量 mod_proxy模 組的轉送過程可能造成的效能影響。

  • 對照組是連線到 https://127.0.0.1:8080/Plone，直接對 Zope Server 進行存取。
  • 實驗組的部分，則是連線到 https://127.0.0.1/Plone 再經由設定好的 mod_proxy 代理存取 Zope Server。
(二) 數據
{mosimage} 
 {mosimage}

(三) 意義
使用 Apache Proxy 模組後：

  • Requests per second 降為 2.46/sec。
  • Time per request 升高為 8125.211 ms。
  • 平均網站效能降低約 5%。
由測試數據中發現，在使用了 mod_proxy 模組之後，網站效能的確受到影響，但所受影響程度相當微小，應不至於成為網站性能的主要瓶頸。

二、RAM Cache Manager

(一) 說明
Plone 中的 RAM Cache Manager 能夠將運算的結果儲存在 Server 記憶體當中，當下次需要的時候，就可以直接從記憶體當中取用，提升網站運作效率。

這個測試的目的，在於評量開啟 Plone 的 RAM Cache Manager 後，對於效能表現有什麼樣的改善。

  • 對照組與實驗組都是直接連線 https://127.0.0.1:8080/Plone。
  • 對照組是在 RAM Cache Manager 關閉的情況下測試。
  • 實驗組是在 RAM Cache Manager 當中，將所有的 Plone 物件加入 RAM Cache 快取清單。
除了下列五個會造成問題的物件，被排除在外：
  • portal_skins/plone_scripts/getOrderedUserActions
  • portal_skins/plone_scripts/getActionIconList
  • portal_skins/plone_scripts/sortObjects
  • portal_skins/plone_scripts/getAllowedTypes
  • portal_skins/plone_scripts/getAddableTypesInMenu
(二) 數據 
{mosimage}
 {mosimage}

(三) 意義
使用 RAM Cache Manager 之後：

  • Requests per second 提高為 52.02/sec。
  • Time per request 降為 384.478 ms。
  • 平均網站效能提升約 20 倍。
不過實際瀏覽時發現一個狀況，就使用 RAM Cache Manager 後的網頁，似乎無法送出正確的編碼標頭，導致網頁會變成亂碼，要手動將瀏覽器的編碼設成 UTF-8。

三、HTTP Cache Manager

(一) 說明
除了 RAM Cache Manager 以外，Zope 提供了另一個快取機制 HTTP Cache Manager。

HTTP Cache Manager 並不直接將結果儲存在記憶體，而是在 HTTP Header 當中加入快取宣告，通知外部的快取主機，將這頁資料儲存起來。

由於 HTTP Cache Manager 只是修改 HTTP Header 而已，實際的快取任務是交由外部主機，因此我們必須搭配 Apache 的 Cache 與 Proxy 模組，來執行快取任務。

  • 對照組與實驗組均連線 https://127.0.0.1/Plone，但對照組關閉 HTTP Cache Manager。
  • 實驗組則加入所有 Plone 物件到 HTTP Cache 快取清單。

(二) 數據

{mosimage} 

 {mosimage}

 

(三) 意義
在開啟 HTTP Cache Manager + Apache mod_cache 後：

  • Requests per second提升為 104.82/sec。
  • Time per request降低為 190.811 ms。
  • 平均網站效能提升約 41 倍。
◎ 綜合結論與建議
 {mosimage}
 {mosimage}
 

使用快取機制，確實能夠對 Plone 的反應有顯著的效能提升。但使用 RAM Cache Manager 雖然有約 20 倍的顯著效果，然卻會產生編碼錯誤的問題，如果無法解決這個問題，將大幅降低其實用性。

根據整個實驗的結論，如果要提升Plone網站的效能，目前建議的組合為：

* (Apache + mod_cache) + (Zope + Plone + 開啟 HTTP Cache Manager)

以 Apache Server 為前端伺服器，然後使用 mod_rewrite、mod_proxy 和 mod_cache 模組作為前端快取機制，並開啟 Plone 的 HTTP Cache Manager，如此將可有效的大幅提升 Plone 網站效能。

在其他的解決方案上，搭配專門的快取軟體如 Squid，或許能得到更好的快取品質，但這部分並不在本次的測試之內。



自由軟體鑄造場電子報 : 第 70 期 Sun 宣佈 Java 將採用 GPL

分類: 技術專欄



↑ Top