硬體調整指南 hardware-sizing-guidelines

CAUTION
AEM 6.4已結束延伸支援,本檔案不再更新。 如需詳細資訊,請參閱 技術支援期. 尋找支援的版本 此處.

這些調整准則提供部署AEM專案所需硬體資源的概約值。 規模估計取決於項目的體系結構、解決方案的複雜性、預期流量和項目要求。 本指南幫助您確定特定解決方案的硬體需求,或查找硬體需求的上下估計值。

要考慮的基本因素為(依此順序):

  • 網路速度

    • 網路延遲
    • 可用頻寬
  • 計算速度

    • 快取效率
    • 預期流量
    • 範本、應用程式和元件的複雜性
    • 同時作者
    • 製作操作的複雜度(簡單的內容編輯、MSM轉出等)
  • I/O效能

    • 檔案或資料庫儲存的效能和效率
  • 硬碟

    • 儲存庫大小至少比它大2或3倍
  • 記憶體

    • 網站大小(內容物件、頁面和使用者數量)
    • 同時處於活動狀態的用戶/會話數

架構 architecture

典型的AEM設定包含製作和發佈環境。 這些環境對基礎硬體大小和系統配置有不同的要求。 有關這兩種環境的詳細考量,請參閱 作者環境發佈環境 區段。

在一般的專案設定中,您有數個環境要在其中預先放置專案階段:

  • 開發環境
    開發新功能或進行重大變更。 最佳實務是使用每個開發人員的開發環境(通常是個人系統上的本機安裝)。

  • 製作測試環境
    驗證變更。 測試環境的數量可能會因專案需求而異(例如,針對QA、整合測試或使用者接受測試而分開)。

  • 發佈測試環境
    主要用於測試社交協作使用案例和/或作者與多個發佈例項之間的互動。

  • 製作生產環境
    供作者編輯內容。

  • 發佈生產環境
    提供已發佈的內容。

此外,環境可能有所不同,從運行AEM的單伺服器系統和應用程式伺服器,到高度擴展的多伺服器、多CPU群集實例集。 建議您為每個生產系統使用單獨的電腦,並且不要在這些電腦上運行其他應用程式。

一般硬體大小考量事項 generic-hardware-sizing-considerations

以下各節提供了如何計算硬體需求的指南,同時考慮到各種因素。 對於大型系統,建議您對參考配置執行一組簡單的內部基準測試。

效能最佳化是一項基本任務,需要先執行,然後才能對特定項目進行任何基準設定。 請務必套用 效能最佳化檔案 執行任何基準測試,並將其結果用於任何硬體大小計算。

高級使用案例的硬體大小要求需要基於對項目的詳細效能評估。 需要特殊硬體資源的高級使用案例的特點包括:

  • 高內容有效負載/吞吐量
  • 廣泛使用自訂程式碼、自訂工作流程或第三方軟體庫
  • 整合不受支援的外部系統

磁碟空間/硬碟 disk-space-hard-drive

所需的磁碟空間與Web應用程式的卷和類型密切相關。 計算時應考慮:

  • 頁面、資產和其他存放庫所儲存實體(例如工作流程、設定檔等)的數量和大小。
  • 估計的內容更改頻率,從而建立內容版本
  • 將產生的DAM資產轉譯數量
  • 內容隨時間的總體增長

在「聯機」和「離線」修訂清除」期間持續監視磁碟空間。 如果可用磁碟空間降至關鍵值以下,該過程將被取消。 關鍵值是儲存庫當前磁碟佔用量的25%,且不可配置。 建議將磁碟的大小至少比儲存庫大小大兩三倍,包括估計的增長。

考慮建立獨立磁碟的冗餘陣列(RAID,如RAID10)以實現資料冗餘。

NOTE
生產實例的臨時目錄應至少具有6 GB的可用空間。

虛擬化 virtualization

AEM在虛擬化環境中運行良好,但可能有CPU或I/O等因素無法直接與物理硬體相等。 建議選擇更高的I/O速度(通常),因為這在大多數情況下是一個關鍵因素。 為環境設定基準,才能精確了解需要哪些資源。

AEM例項的平行化 parallelization-of-aem-instances

失敗安全性 fail-safeness

在至少兩個不同的系統上部署了故障保護網站。 如果一個系統出現故障,另一個系統可以接管並因此補償系統故障。

系統資源可擴充性 system-resources-scalability

當所有系統都在運行時,可以提高計算效能。 額外效能不一定與群集節點數量呈線性關係,因為這種關係高度依賴於技術環境;請參閱 叢集檔案 以取得更多資訊。

根據特定Web項目的基本要求和具體使用情況,對需要的簇節點數進行估計:

  • 從失敗安全性的角度來看,對於所有環境,必鬚根據群集節點恢復所需的時間來確定關鍵故障的程度和故障補償時間。
  • 在可擴充性方面,寫操作的數量基本上是最重要的因素;請參閱 作者並行工作 為製作環境和 社交協作 (適用於發佈環境)。 可以為僅僅為了處理讀取操作而訪問系統的操作建立負載平衡;請參閱 Dispatcher 以取得詳細資訊。

製作環境特定計算 author-environment-specific-calculations

為了設定基準,Adobe已針對獨立製作例項開發了一些基準測試。

  • 基準測試1

    計算載入設定檔的最大吞吐量,其中使用者在300個現有頁面的基本載入上,執行簡單的建立頁面練習,而所有的現有頁面都具有類似的性質。 相關步驟包括登入網站、建立含有SWF和影像/文字的頁面、新增標籤雲,然後啟用頁面。

    • 結果

      如上所示,簡單頁面建立練習(視為一個交易)的吞吐量上限為1730個交易/小時。

  • 基準測試2

    當載入設定檔混合了全新頁面建立(10%)、修改現有頁面(80%)和建立然後連續修改頁面(10%)時,計算最大吞吐量。 頁面的複雜度與基準測試1的設定檔相同。 基本修改頁面的方式為新增影像及修改文字內容。 同樣地,此練習是在300頁的基礎載入上執行的,其複雜度與基準測試1中定義的相同。

    • 結果

      發現這種混合操作方案的最大吞吐量為每小時3252個事務。

NOTE
吞吐量速率不區分負載配置檔案中的事務類型。 用於測量吞吐量的方法確保每個類型的事務的固定比例包含在工作負載中。

上述兩項測試清楚強調吞吐量會因操作類型而異。 使用您環境中的活動作為調整系統大小的基礎。 通過修改等較少的操作(這也更常見),您將獲得更好的吞吐量。

快取 caching

在製作環境中,快取效率通常會低很多,因為網站的變更更頻繁,而且內容的互動性和個人化程度也很高。 使用Dispatcher,您可以快取AEM程式庫、JavaScripts、CSS檔案和版面影像。 這可加速製作程式的某些方面。 將Web伺服器設定為額外設定標頭,以便在這些資源上快取瀏覽器,將減少HTTP要求的數量,進而改善作者所體驗的系統回應能力。

作者並行工作 authors-working-in-parallel

在作者環境中,並行工作的作者數量,以及他們交互的載入是系統的主要限制因素。 因此,我們建議您根據資料的共用吞吐量來調整系統規模。

對於這類情況,Adobe在兩個節點的無共用製作例項叢集上執行基準測試。

  • 基準測試1a

    若使用2個製作例項的主動 — 主動 — 無共用叢集,透過載入設定檔計算最大吞吐量,使用者可在300個現有頁面的基本載入上,執行簡單的建立頁面練習,而且性質都類似。

    • 結果

      如上所述,簡單頁面建立練習(視為一個交易)的最大吞吐量為2016年交易/小時。 與相同基準測試的獨立製作例項相比,這大約增加16%。

  • 基準測試2b

    若使用2個製作例項的主動 — 主動 — 無共用叢集,當載入設定檔混合了全新頁面建立(10%)、修改現有頁面(80%)以及連續建立和修改頁面(10%)時,就會計算最大吞吐量。 頁面的複雜度與基準測試1的設定檔相同。 基本修改頁面的方式為新增影像及修改文字內容。 同樣地,此練習是在300頁複雜度的基礎載入上執行的,與基準測試1中定義的相同。

    • 結果

      發現這種混合操作方案的最大吞吐量為6288個事務/小時。 與相同基準測試的獨立製作例項相比,這大約增加93%。

NOTE
吞吐量速率不區分負載配置檔案中的事務類型。 用於測量吞吐量的方法確保每個類型的事務的固定比例包含在工作負載中。

上述兩項測試清楚強調,AEM可針對使用AEM執行基本編輯作業的作者進行良好的擴充。 一般而言,AEM在縮放讀取操作方面最有效。

在一般的網站上,大部分的製作都發生在專案階段。 網站上線後,平行工作的作者人數通常會降至較低(運作模式)的平均值。

您可以依下列方式計算製作環境所需的電腦(或CPU)數量:

n = numberOfParallelAuthors / 30

當作者使用AEM執行基本操作時,此公式可作為調整CPU規模的一般准則。 假設系統和應用程式已經優化。 不過,進階功能(例如MSM或資產)的公式將不會成立(請參閱下節)。

另請參閱 並行化效能最佳化.

硬體Recommendations hardware-recommendations

通常,您的製作環境可使用與發佈環境建議相同的硬體。 通常製作系統的網站流量會低很多,但快取效率也會低。 然而,這裡的基本因素是,同時工作的作者人數,以及正在對系統採取的行動類型。 一般而言,AEM叢集(作者環境)對縮放讀取操作最為有效;換句話說,AEM叢集可與執行基本編輯作業的作者妥善調整。

Adobe的基準測試是使用RedHat 5.5作業系統執行的,該作業系統運行在Hewlett-Packard ProLiant DL380 G5硬體平台上,配置如下:

  • 兩個四核英特爾至強X5450 CPU,3.00GHz
  • 8 GB RAM
  • Broadcom NetXtreme II BCM5708千兆乙太網
  • HP智慧陣列RAID控制器,256 MB快取
  • 兩個146 GB 10,000 RPM SAS磁碟配置為RAID0條帶集
  • SPEC CINT2006比率基準分數為110

AEM執行個體的堆大小最小為256M,堆大小最大為1024M。

發佈環境特定計算 publish-environment-specific-calculations

快取效率和流量 caching-efficiency-and-traffic

快取效率對於網站速度至關重要。 下表顯示最佳化AEM系統可使用反向代理(例如Dispatcher)每秒處理多少頁:

快取比
頁面/秒(尖峰)
百萬頁/日(平均值)
100%
1000-2000
35-70
99%
910
32
95%
690
25
90%
520
18
60%
220
8
0%
100
3.5
CAUTION
免責聲明:這些數字基於預設硬體配置,並且可能根據使用的特定硬體而有所不同。

快取比率是調度程式無須存取AEM即可傳回的頁面百分比。 100%表示Dispatcher會回應所有請求,0%表示AEM會計算每個單一頁面。

範本和應用程式的複雜性 complexity-of-templates-and-applications

如果您使用複雜範本AEM,則需要更多時間來轉譯頁面。 從快取取的頁面不受此影響,但考慮整體回應時間時,頁面大小仍相關。 轉譯複雜頁面所花的時間,可能會比轉譯簡單頁面長10倍。

公式 formula

使用下列公式,您可以計算AEM解決方案整體複雜度的預估值:

complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)

您可以根據複雜性決定發佈環境所需的伺服器(或CPU核心)數量,如下所示:

n = (traffic * complexity / 1000 ) * activations

方程式中的變數如下:

流量
預期的每秒峰值流量。 您可以將此值估計為每天的頁面點擊數除以35'000。
applicationComplexy

對簡單應用程式使用1,對複雜應用程式使用2,或者對應一個值:

  • 1 — 完全匿名、以內容為導向的網站
  • 1.1 — 具有用戶端/Target個人化的完全匿名內容導向網站
  • 1.5 — 內容導向網站,包含匿名和登入區段、用戶端/Target個人化
  • 1.7 — 針對同時具有匿名和登入區段的內容導向網站、用戶端/Target個人化以及某些使用者產生的內容
  • 2 — 整個網站需要登入的位置,可廣泛使用使用者產生的內容和各種個人化技術
cacheRatio
來自Dispatcher快取的頁面百分比。 如果所有頁面皆來自快取,請使用1;如果每個頁面皆由AEM計算,則使用0。
templateComplexic
使用介於1到10之間的值來表示範本的複雜性。 數字越高,範本越複雜,每頁平均有10個元件的網站值1,平均有40個元件的網頁值5,平均有10個元件的網頁值1。
啟用
每小時平均啟動次數(將平均大小的頁面和資產從作者複製到發佈層級)除以x,其中x是在系統上完成的啟動次數,不會對系統處理的其他任務造成效能副作用。 您也可以預先定義悲觀的初始值,例如x = 100。

如果您有更複雜的網站,您還需要更強大的Web伺服器,讓AEM能在可接受的時間回應請求。

  • 複雜度低於4:

    • 1024 MB JVM RAM(&A);
    • 中低效能CPU
  • 4到8之間的複雜性:

    • 2048 MB JVM RAM(&A);
    • 中高效能CPU
  • 複雜度超過8:

    • 4096 MB JVM RAM(&A);
    • 高到高效能CPU
NOTE
*除了JVM所需的記憶體外,還為作業系統保留足夠的記憶體。

其他使用案例特定計算 additional-use-case-specific-calculations

除了預設Web應用程式的計算外,您可能需要針對下列使用案例考慮特定因素。 計算值將添加到預設計算。

特定資產考量事項 assets-specific-considerations

大量處理數字資產需要優化的硬體資源,最相關的因素是影像大小和處理後影像的峰值吞吐量。

分配至少16GB的堆,並設定DAM更新資產工作流程以使用 Camera Raw套件 用於擷取原始影像。

NOTE
影像的吞吐量越高,表示計算資源需要能夠跟上系統I/O,反之亦然。 例如,如果工作流程是透過匯入影像來啟動,則透過WebDAV上傳許多影像可能會造成工作流程積壓。
對TarPM、資料儲存和搜索索引使用單獨的磁碟有助於優化系統I/O行為(但通常將搜索索引保持在本地是合理的)。
NOTE
另請參閱 資產效能指南.

多網站管理員 multi-site-manager

在製作環境上使用AEM MSM時的資源耗用量,很大程度上取決於特定的使用案例。 基本因素包括:

  • 即時副本數
  • 轉出的週期
  • 要推出的內容樹大小
  • 轉出動作的連線功能

使用代表性內容摘要來測試規劃的使用案例,可協助您進一步了解資源耗用量。 如果您以計畫的吞吐量推斷結果,則可評估AEM MSM所需的額外資源。

另外也請考量,如果AEM MSM使用案例消耗的資源超過計畫,同時工作的作者會察覺效能的副作用。

AEM Communities大小調整考量事項 aem-communities-sizing-considerations

包含AEM Communities功能(社群網站)的AEM網站,會在發佈環境中與網站訪客(成員)進行高層互動。

社群網站的大小考量事項取決於社群成員的預期互動,以及頁面內容的最佳效能是否更重要。

用戶生成的內容(UGC)提交成員與頁面內容分開儲存。 雖然AEM平台使用節點存放區將網站內容從製作複製到發佈,但AEM Communities卻使用單一、通用的存放區,用於從未複製過的UGC。

對於UGC儲存,必須選擇儲存資源提供程式(SRP),這會影響所選部署。
請參閱

recommendation-more-help
d284b6a8-dae4-4549-aa9e-2b09317eb02a