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

Plone 效能測試綜合報告

◎ 前言

網站效率,一直是網站件置過程中首要被關注的議題。而由於 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

分類: 技術專欄