硬體調整指南 hardware-sizing-guidelines
這些調整准則提供部署AEM專案所需硬體資源的概約值。 規模估計取決於項目的體系結構、解決方案的複雜性、預期流量和項目要求。 本指南幫助您確定特定解決方案的硬體需求，或查找硬體需求的上下估計值。
要考慮的基本因素為（依此順序）:
-
網路速度
- 網路延遲
- 可用頻寬
-
計算速度
- 快取效率
- 預期流量
- 範本、應用程式和元件的複雜性
- 同時作者
- 製作操作的複雜度（簡單的內容編輯、MSM轉出等）
-
I/O效能
- 檔案或資料庫儲存的效能和效率
-
硬碟
- 儲存庫大小至少比它大2或3倍
-
記憶體
- 網站大小（內容物件、頁面和使用者數量）
- 同時處於活動狀態的用戶/會話數
架構 architecture
典型的AEM設定包含製作和發佈環境。 這些環境對基礎硬體大小和系統配置有不同的要求。 有關這兩種環境的詳細考量，請參閱 作者環境 和 發佈環境 區段。
在一般的專案設定中，您有數個環境要在其中預先放置專案階段：
-
開發環境
開發新功能或進行重大變更。 最佳實務是使用每個開發人員的開發環境（通常是個人系統上的本機安裝）。 -
製作測試環境
驗證變更。 測試環境的數量可能會因專案需求而異（例如，針對QA、整合測試或使用者接受測試而分開）。 -
發佈測試環境
主要用於測試社交協作使用案例和/或作者與多個發佈例項之間的互動。 -
製作生產環境
供作者編輯內容。 -
發佈生產環境
提供已發佈的內容。
此外，環境可能有所不同，從運行AEM的單伺服器系統和應用程式伺服器，到高度擴展的多伺服器、多CPU群集實例集。 建議您為每個生產系統使用單獨的電腦，並且不要在這些電腦上運行其他應用程式。
一般硬體大小考量事項 generic-hardware-sizing-considerations
以下各節提供了如何計算硬體需求的指南，同時考慮到各種因素。 對於大型系統，建議您對參考配置執行一組簡單的內部基準測試。
效能最佳化是一項基本任務，需要先執行，然後才能對特定項目進行任何基準設定。 請務必套用 效能最佳化檔案 執行任何基準測試，並將其結果用於任何硬體大小計算。
高級使用案例的硬體大小要求需要基於對項目的詳細效能評估。 需要特殊硬體資源的高級使用案例的特點包括：
- 高內容有效負載/吞吐量
- 廣泛使用自訂程式碼、自訂工作流程或第三方軟體庫
- 整合不受支援的外部系統
磁碟空間/硬碟 disk-space-hard-drive
所需的磁碟空間與Web應用程式的卷和類型密切相關。 計算時應考慮：
- 頁面、資產和其他存放庫所儲存實體（例如工作流程、設定檔等）的數量和大小。
- 估計的內容更改頻率，從而建立內容版本
- 將產生的DAM資產轉譯數量
- 內容隨時間的總體增長
在「聯機」和「離線」修訂清除」期間持續監視磁碟空間。 如果可用磁碟空間降至關鍵值以下，該過程將被取消。 關鍵值是儲存庫當前磁碟佔用量的25%，且不可配置。 建議將磁碟的大小至少比儲存庫大小大兩三倍，包括估計的增長。
考慮建立獨立磁碟的冗餘陣列（RAID，如RAID10）以實現資料冗餘。
虛擬化 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個事務。
-
上述兩項測試清楚強調吞吐量會因操作類型而異。 使用您環境中的活動作為調整系統大小的基礎。 通過修改等較少的操作（這也更常見），您將獲得更好的吞吐量。
快取 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%。
-
上述兩項測試清楚強調，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）每秒處理多少頁：
快取比率是調度程式無須存取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
方程式中的變數如下：
如果您有更複雜的網站，您還需要更強大的Web伺服器，讓AEM能在可接受的時間回應請求。
-
複雜度低於4:
- 1024 MB JVM RAM(&A);
- 中低效能CPU
-
4到8之間的複雜性：
- 2048 MB JVM RAM(&A);
- 中高效能CPU
-
複雜度超過8:
- 4096 MB JVM RAM(&A);
- 高到高效能CPU
其他使用案例特定計算 additional-use-case-specific-calculations
除了預設Web應用程式的計算外，您可能需要針對下列使用案例考慮特定因素。 計算值將添加到預設計算。
特定資產考量事項 assets-specific-considerations
大量處理數字資產需要優化的硬體資源，最相關的因素是影像大小和處理後影像的峰值吞吐量。
分配至少16GB的堆，並設定DAM更新資產工作流程以使用 Camera Raw套件 用於擷取原始影像。
多網站管理員 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)，這會影響所選部署。
請參閱