硬體尺寸指南

這些調整大小准則提供部署AEM專案所需硬體資源的近似值。 規模估計取決於項目的體系結構、解決方案的複雜性、預期流量和項目需求。 本指南可協助您判斷特定解決方案的硬體需求，或找出硬體需求的上限和下限估計值。

要考慮的基本因素有：

• 網路速度

  • 網路延遲
  • 可用頻寬

• 計算速度

  • 快取效率
  • 預期流量
  • 範本、應用程式和元件的複雜性
  • 並行作者
  • 製作作業的複雜性（簡單的內容編輯、MSM的推出等）

• I/O效能

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

• 硬碟

  • 至少是儲存庫大小的二、三倍

• 記憶體

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

架構

典型的AEM設定由作者和發佈環境組成。 這些環境對底層硬體大小和系統配置有不同的要求。 作者環境和發佈環境章節中對這兩種環 境的詳細考 量進行了說明 。

在典型的項目設定中，您有幾個環境要在其上進行項目階段：

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

• 製作測試環境：驗證變更。 測試環境的數量可能因專案需求而異（例如，針對QA、整合測試或使用者驗收測試分別進行）。

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

• 製作製作環境：讓作者編輯內容。

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

此外，環境可能會有所不同，從執行AEM的單一伺服器系統和應用程式伺服器，到高度擴充的多伺服器、多CPU叢集例項集。 我們建議您針對每個生產系統使用個別的電腦，而且不要在這些電腦上執行其他應用程式。

一般硬體大小考量

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

效能最佳化是一項基本工作，必須先執行，才能針對特定專案進行基準評估。 在執行任何基準測試並使用其結果進行任何硬體尺寸計算之前，請務必套用「 效能最佳化」檔案中提供的建議 。

高級使用案例的硬體規模要求必須基於項目的詳細效能評估。 需要卓越硬體資源的高級使用案例的特點包括：

• 高內容負載／吞吐量
• 廣泛使用自訂的程式碼、自訂的工作流程或協力廠商的軟體程式庫
• 與不支援的外部系統整合

磁碟空間／硬碟

所需的磁碟空間很大程度上取決於Web應用程式的卷和類型。 計算時應考慮：

• 頁面、資產和其他儲存庫儲存實體（如工作流、配置檔案等）的數量和大小。
• 估計的內容變更頻率，因此建立內容版本
• 將產生的DAM資產轉譯的量
• 隨著時間推移，內容的整體成長

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

考慮為資料冗餘設定獨立磁碟冗餘陣列（RAID，如RAID10）。

虛擬化

AEM在虛擬化環境中運作良好，但可能有CPU或I/O等因素無法直接與物理硬體相等。 建議選擇較高的I/O速度（一般而言），因為這在大多數情況下都是關鍵因素。 對您的環境進行基準評估是必要的，以便精確瞭解所需的資源。

AEM例項的並行化

失敗安全性

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

系統資源調整能力

當所有系統都在運行時，可提高計算效能。 這種附加效能不一定與群集節點的數量成線性關係，因為這種關係高度依賴於技術環境； 有關詳細資訊，請 參閱群集 文檔。

根據具體Web項目的基本要求和具體使用案例，對需要多少簇節點進行估計：

• 從故障安全性的角度來看，對於所有環境，必鬚根據群集節點恢復所需的時間來確定關鍵故障的嚴重程度和故障補償時間。
• 在可擴充性方面，寫操作的數量基本上是最重要的因素； 請參 閱作者平行工作 ，以瞭解作者環境，以及 發佈環境的Social Collaboration 。 對於僅為處理讀取操作而訪問系統的操作，可以建立負載平衡； 如需詳 細資訊 ，請參閱Dispatcher。

編寫環境特定計算

為了進行基準測試，Adobe已針對獨立作者例項開發了一些基準測試。

• 基準測試1

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

  • 結果

    如上所述（視為一項交易），簡單頁面建立作業的最大吞吐量為1730個交易／小時。

• 基準測試2

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

  • 結果

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

上述兩項測試清楚指出吞吐量會依作業類型而有所不同。 使用您環境中的活動作為調整系統大小的基礎。 您可以使用較少密集的動作（例如修改）獲得更高的吞吐量（這也比較常見）。

快取

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

作者並行工作

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

對於這類情況，Adobe在兩個節點無共用的作者實例群集上執行基準測試。

• 基準測試1a

  使用包含2個作者例項的主動——主動——主動——無共用叢集，使用載入描述檔計算最大吞吐量，其中使用者在300個現有頁面的基本載入上執行簡單的建立頁面練習，而所有這些都是類似的性質。

  • 結果

    如上所述，簡單頁面建立練習（視為一項交易）的最大吞吐量為2016年交易／小時。 相較於相同基準測試的獨立作者例項，這大約增加了16%。

• 基準測試2b

  使用包含2個作者實例的活動——活動——無共用集群，當載入描述檔混合了新建頁面(10%)、修改現有頁面(80%)以及連續建立和修改頁面(10%)時，計算最大吞吐量。 頁面的複雜性與基準測試1的設定檔相同。 基本修改頁面的方式是新增影像和修改文字內容。 同樣地，在300頁的基礎負載（與基準測試1中定義的相同）上執行了本練習。

  • 結果

    發現這種混合操作方案的最大吞吐量為6288個事務／小時。 相較於相同基準測試的獨立作者例項，這大約增加了93%。

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

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

您可以按如下方式計算作者環境所需的電腦（或CPU）數：

n = numberOfParallelAuthors / 30

當作者使用AEM執行基本作業時，此公式可做為縮放CPU的一般准則。 它假定系統和應用程式已優化。 不過，進階功能（例如MSM或Assets）的公式不適用（請參閱以下各節）。

另請參閱「並行化」和「性 能優化 」 的其他注釋。

硬體建議

通常，您可以針對您的作者環境使用與發佈環境建議相同的硬體。 通常，網站流量在製作系統上要低得多，但快取效率也更低。 然而，這裡的根本因素是，有多少作者同時工作，以及正在對系統採取的行動類型。 一般而言，AEM叢集（作者環境）在縮放讀取作業方面最為有效； 換言之，AEM叢集可與執行基本編輯作業的作者進行良好的縮放。

Adobe的基準測試是使用RedHat 5.5作業系統執行，此作業系統在Hewlett-Packard ProLiant DL380 G5硬體平台上執行，並具備下列組態：

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

AEM例項的最小堆大小為256M，最大堆大小為1024M。

發佈環境特定計算

快取效率與流量

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

快取比	頁面／秒（尖峰）	百萬頁／日（平均值）
100%	1000-2000	35-70
99%	910	32
95%	690	25
90%	520	18
60%	220	8
0%	100	3.5

快取比率是調度器可傳回的頁面百分比，不需存取AEM。 100%表示分派程式會回應所有請求，0%表示AEM會計算每個頁面。

範本和應用程式的複雜性

如果您使用複雜範本，AEM將需要更多時間來轉譯頁面。 從快取擷取的頁面不受此影響，但在考慮整體回應時間時，頁面大小仍然相關。 轉換複雜頁面的時間，會比轉換簡單頁面輕鬆十倍。

公式

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

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

根據複雜性，您可以確定發佈環境所需的伺服器（或CPU內核）數量，如下所示：

n = (traffic * complexity / 1000 ) * activations

方程式中的變數如下：

流量	預期的每秒峰值流量。 您可以估計每日頁面點擊數除以35000。
applicationComplexicy	使用1代表簡單應用程式，2代表複雜應用程式，或介於以下兩者之間的值： 1 —— 完全匿名的內容導向網站 1.1 —— 具備用戶端/Target個人化功能的完全匿名內容導向網站 1.5 —— 內容導向網站，包含匿名和登入區段、用戶端/Target個人化 1.7 —— 適用於具有匿名和登入區段的內容導向網站、用戶端/Target個人化以及部分使用者產生的內容 2 —— 整個網站需要登入的地方，廣泛運用使用者產生的內容和各種個人化技術
cacheRatio	調度器快取中的頁數百分比。 如果所有頁面都來自快取，請使用1；如果每個頁面都由AEM計算，則使用0。
templateComplexicy	使用1到10之間的值來表示範本的複雜性。 數字越高，表示範本越複雜，每頁平均10個元件的網站使用值1，頁面平均40個元件使用值5，平均100多個元件使用值10。
啟動	每小時平均啟動次數（將平均大小的頁面和資產從作者複製到發佈層）除以x，其中x是在系統上執行的啟動次數，對系統處理的其他任務沒有效能副作用。 您也可以預先定義悲觀的初始值，例如x = 100。

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

• 複雜性低於4:

  • 1024 MB JVM RAM*
  • 中低效能CPU

• 4到8之間的複雜性：

  • 2048 MB JVM RAM*
  • 中高效能CPU

• 複雜性高於8:

  • 4096 MB JVM RAM*
  • 高到高效能CPU

其他使用案例特定計算

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

資產特定考量事項

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

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

多網站管理員

在製作環境上使用AEM MSM時的資源耗用量，主要取決於特定的使用案例。 基本因素包括：

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

使用代表性內容摘錄來測試計畫的使用案例，可協助您提高對資源消耗的瞭解。 如果您以計畫的總處理能力來推算結果，則可評估AEM MSM所需的額外資源。

請同時考慮，如果AEM MSM使用案例所消耗的資源超過計畫，並行工作的作者將會察覺效能副作用。

AEM Communities大小考量

包含AEM Communities功能（社群網站）的AEM網站在發佈環境中體驗到來自網站訪客（成員）的高層互動。

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

使用者產生的內容(UGC)提交的成員會與頁面內容分開儲存。 雖然AEM平台使用節點儲存區將網站內容從作者複製到發佈，但AEM Communities會針對從未複製的UGC使用單一的通用儲存區。

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

• 社群內容儲存
• 推薦的社區拓撲