硬體大小調整准則

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

要考量的基本因素包括（依此順序）：

• 網路速度

  • 網路延遲
  • 可用頻寬

• 運算速度

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

• I/O效能

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

• 硬碟

  • 至少比存放庫大小大兩到三倍

• 記憶體

  • 網站大小（內容物件、頁面和使用者數量）
  • 同時處於作用中狀態的使用者/工作階段數目

架構

典型的AEM設定包含作者和發佈環境。 這些環境對於基礎硬體大小和系統組態有不同的需求。 有關這兩種環境的詳細考量事項說明，請參見 作者環境 和 發佈環境 區段。

在典型的專案設定中，您有幾個環境要中繼專案階段：

• 開發環境
  開發新功能或進行重大變更。 最佳實務是為每位開發人員使用開發環境（在其個人系統上的本機安裝）來運作。

• 作者測試環境
  驗證變更。 測試環境的數量會依專案需求而有所不同（例如，QA、整合測試或使用者驗收測試會分開）。

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

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

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

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

一般硬體大小調整考量事項

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

效能最佳化是一項基本工作，必須先執行，才能對特定專案進行任何基準測試。 請務必套用 效能最佳化檔案 執行任何效能標竿測試並將其結果用於任何硬體大小計算之前。

進階使用案例的硬體大小需求需要以專案的詳細效能評估為基礎。 需要特殊硬體資源的進階使用案例的特徵包括以下組合：

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

磁碟空間/硬碟

所需的磁碟空間在很大程度上取決於您的Web應用程式的磁碟區和型別。 計算時應考慮以下因素：

• 頁面、資產和其他儲存庫儲存的實體（例如工作流程、設定檔等）的數量和大小。
• 預估的內容變更頻率，進而建立內容版本
• 將產生的DAM資產轉譯數量
• 一段時間內內容的整體成長

線上上和離線修訂清除期間，會持續監視磁碟空間。 如果可用磁碟空間下降到關鍵值以下，則取消此程式。 關鍵值是存放庫目前磁碟空間的25%，且無法設定。 Adobe建議磁碟的大小至少比存放庫大小（包括預估成長）大2或3倍。

請考慮設定獨立磁碟的備援陣列（例如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資料庫、JavaScript、CSS檔案和版面影象。 如此可加快編寫程式的某些方面。 設定網頁伺服器也可在這些資源上設定瀏覽器快取的標頭，以減少HTTP請求的數量，從而提高系統回應速度，與作者一樣好。

同時工作的作者

在作者環境中，同時工作的作者人數及其互動增加到系統的負載是主要限制因素。 因此，Adobe建議您根據共用的資料輸送量來擴充系統。

對於這類情況，Adobe會在作者執行個體的兩個非共用節點叢集上執行基準測試。

• 效能標竿測試1a
  使用2個製作執行個體的active-active shared-nothing叢集，使用載入設定檔計算最大輸送量，使用者在具有300個現有頁面的基本載入上執行簡單的建立頁面練習，所有這些都具有類似的性質。

  • 結果
    如上所示的簡單頁面建立練習（視為一項交易）的最大輸送量，為2016交易/小時。 相較於相同效能標竿測試的獨立編寫執行個體，大約增加16%。

• 效能標竿測試2b
  使用2個製作執行個體的active-active shared-nothing叢集，計算載入設定檔混合新頁面建立(10%)、修改現有頁面(80%)以及連續建立和修改頁面(10%)時的最大輸送量。 頁面的複雜度與效能標竿測試1的設定檔相同。 頁面的基本修改是透過新增影像並修改文字內容來完成。 同樣地，此練習是在基礎負載300頁（與效能標竿測試1中定義相同）的複雜性之上執行。

  • 結果
    發現此類混合作業案例的最大輸送量為6288個交易/小時。 相較於相同效能標竿測試的獨立編寫執行個體，大約增加了93%。

上述兩項測試清楚表明，AEM適合使用AEM執行基本編輯操作的作者。 一般而言，AEM在縮放讀取作業方面最有效。

在典型的網站上，大部分的撰寫都會在專案階段進行。 網站上線後，同時作業的作者人數通常會降至較低（作業模式）的平均值。

您可以計算製作環境所需的電腦（或CPU）數量，如下所示：

n = numberOfParallelAuthors / 30

當作者使用AEM執行基本作業時，此公式可作為調整CPU比例的一般准則。 它假設系統和應用程式已最佳化。 不過，MSM或Assets等進階功能的公式不成立（請參閱以下章節）。

另請參閱 平行化 和 效能最佳化.

硬體Recommendations

通常，您可以依照發佈環境的建議，對製作環境使用相同的硬體。 一般而言，編寫系統的網站流量會低得多，但快取效率也較低。 不過，這裡的基本因素是同時工作的作者數量，以及對系統執行的動作型別。 一般而言，AEM叢集（作者環境）在縮放讀取作業方面最有效；換言之，AEM叢集可配合執行基本編輯作業的作者進行良好的縮放。

Adobe時的效能標竿測試是使用Red Hat® 5.5作業系統執行，在Hewlett-Packard ProLiant DL380 G5硬體平台上執行，並具有下列組態：

• 兩個四核心Intel Xeon® X5450 CPU，3.00 GHz
• 8 GB RAM
• Broadcom NetXtreme II BCM5708 Gigabit乙太網路
• HP Smart Array RAID控制器，256-MB快取記憶體
• 2個146 GB 10,000-RPM SAS磁碟，配置為RAID0磁條組
• SPEC CINT2006評比基準分數為110

AEM執行個體在執行時的最小棧積大小為256M，最大棧積大小為1024M。

發佈環境特定計算

快取效率和流量

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

快取比率是Dispatcher在無須存取AEM的情況下可傳回的頁面百分比。 100%表示Dispatcher回應所有請求，0%表示AEM計算每個頁面。

範本和應用程式的複雜性

如果您使用複雜的範本，AEM將需要更多時間才能呈現頁面。 從快取中取得的頁面不會受此影響，但在考慮整體回應時間時，頁面大小仍然相關。 轉譯複雜頁面所花的時間很容易比轉譯簡單頁面多十倍。

公式

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

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

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

n = (traffic * complexity / 1000 ) * activations

方程式中的變數如下：

如果您的網站較為複雜，則還需要功能較強大的網頁伺服器，讓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)，這會影響所選的部署。
請參閱

• 社群內容儲存
• 社群適用的建議拓撲

Business.Adobe.com 資源

Ecommerce Integrations Auto Form Fill Asset Collections Version History Customer Experience Management Headless Cms