硬體大小調整准則 hardware-sizing-guidelines
這些大小調整准則提供部署AEM專案所需硬體資源的近似值。 預估規模取決於專案的架構、解決方案的複雜性、預期的流量和專案需求。 本指南可協助您判斷特定解決方案的硬體需求，或尋找硬體需求的上限與下限。
要考量的基本因素為（依此順序）：
-
網路速度
- 網路延遲
- 可用頻寬
-
運算速度
- 快取效率
- 預期流量
- 範本、應用程式和元件的複雜性
- 同時作者
- 製作操作的複雜性（簡單內容編輯、MSM轉出等）
-
I/O效能
- 檔案或資料庫儲存的效能和效率
-
硬碟
- 至少比存放庫大小大兩到三倍
-
記憶體
- 網站的大小（內容物件、頁面和使用者數量）
- 同時處於作用中狀態的使用者/工作階段數目
架構 architecture
典型的AEM設定包含作者和發佈環境。 這些環境對於基礎硬體大小和系統組態有不同的需求。 有關這兩個環境的詳細考量事項，請參見 作者環境 和 發佈環境 區段。
在典型的專案設定中，您有幾個環境要中繼專案階段：
-
開發環境
開發新功能或進行重大變更。 最佳實務是為每位開發人員使用開發環境（在其個人系統上安裝本機）來運作。 -
作者測試環境
驗證變更。 測試環境的數量可能會因專案需求而異（例如，針對QA、整合測試或使用者驗收測試而分開）。 -
發佈測試環境
主要用於測試社交合作使用案例和/或作者與多個發佈執行個體之間的互動。 -
製作生產環境
供作者編輯內容。 -
發佈生產環境
提供已發佈的內容。
此外，環境可能會有所不同，從執行AEM的單伺服器系統和應用程式伺服器，到高度擴充的多伺服器、多CPU叢集執行個體集。 Adobe建議您為每個生產系統使用個別的電腦，並且不要在這些電腦上執行其他應用程式。
一般硬體大小調整考量事項 generic-hardware-sizing-considerations
以下各節提供如何計算硬體需求的指引，將各種考量因素納入考量。 對於大型系統，Adobe建議您在參考組態上執行一組簡單的內部基準測試。
效能最佳化是一項基本工作，必須先執行，才能對特定專案進行任何基準測試。 請務必套用 效能最佳化檔案 執行任何效能標竿測試，並將結果用於任何硬體大小計算之前。
進階使用案例的硬體大小需求需要以專案的詳細效能評估為基礎。 需要特殊硬體資源的進階使用案例的特徵包括以下組合：
- 高內容裝載/輸送量
- 廣泛使用自訂程式碼、自訂工作流程或第三方軟體程式庫
- 與不支援的外部系統整合
磁碟空間/硬碟 disk-space-hard-drive
所需的磁碟空間在很大程度上取決於您的Web應用程式的磁碟區和型別。 計算時應考慮以下因素：
- 頁面、資產和其他儲存庫儲存的實體（例如工作流程、設定檔等）的數量和大小。
- 內容變更進而建立內容版本的預估頻率
- 將產生的DAM資產轉譯數量
- 一段時間內內容的整體成長
線上上和離線修訂清除期間，會持續監視磁碟空間。 如果可用磁碟空間下降到臨界值以下，則會取消此程式。 關鍵值是存放庫目前磁碟空間的25%，且無法設定。 Adobe建議將磁碟大小調整為存放庫大小（包括預估成長量）至少兩到三倍。
請考慮設定獨立磁碟的備援陣列（例如RAID10）以取得資料備援。
虛擬化 virtualization
AEM在虛擬化環境中運作良好，但可能有CPU或I/O等因素無法直接等同於實體硬體。 建議選擇較高的I/O速度（一般而言），因為這是關鍵因素，通常是。 設定環境基準是準確瞭解所需資源的必要條件。
AEM執行個體的平行化 parallelization-of-aem-instances
失敗安全性
一個防故障的網站會部署在至少兩個不同的系統上。 如果一個系統發生故障，另一個系統可以接管，從而補償系統故障。
系統資源擴充性
當所有系統都在執行時，可提供更優異的運算效能。 這種額外效能不一定與叢集節點數量成線性關係，因為這種關係在很大程度上取決於技術環境。 另請參閱 叢集檔案 以取得詳細資訊。
預估需要多少叢集節點是根據基本需求及特定Web專案的特定使用案例而定：
- 從故障安全的角度來看，必須根據叢集節點復原所需的時間，決定所有環境的嚴重故障以及故障補償時間。
- 在擴充性方面，寫入作業的數目基本上是最重要的因素；請參閱 同時工作的作者 （針對作者環境和） Social Collaboration 用於發佈環境。 可以針對僅存取系統的作業建立負載平衡，以處理讀取作業；請參閱 Dispatcher 以取得詳細資訊。
作者環境特定的計算 author-environment-specific-calculations
為了進行基準測試，Adobe已針對獨立製作例項開發了一些基準測試。
-
基準測試1
計算載入設定檔的最大輸送量，使用者可在具有類似性質的300個現有頁面之基礎載入之上，執行簡單的建立頁面練習。 相關步驟包括登入網站、建立具有SWF和影像/文字的頁面、新增標籤雲端，然後啟動頁面。- 結果
如上所示的簡單頁面建立練習的最大輸送量（視為一個交易）為每小時1730筆交易。
- 結果
-
基準測試2
當載入設定檔混合有新頁面建立(10%)、修改現有頁面(80%)以及連續建立或修改頁面(10%)時，計算最大輸送量。 頁面的複雜度與效能標竿測試1的設定檔相同。 頁面的基本修改是透過新增影像並修改文字內容來完成。 同樣地，此練習是在基礎負載300個頁面之上執行，這些頁面與基準測試1中定義的複雜性相同。- 結果
發現此類混合作業案例的最大輸送量為每小時3252個交易。
- 結果
上述兩項測試清楚顯示輸送量會因作業型別而異。 使用您環境上的活動作為調整系統大小的基礎。 透過諸如修改（這也是更常見的情況）等不太密集的動作，可以獲得更好的輸送量。
快取 caching
在製作環境中，快取效率通常會低很多，因為網站變更更頻繁，內容也高度互動和個人化。 使用Dispatcher，您可以快取AEM資料庫、JavaScript、CSS檔案和版面配置影像。 如此可加速編寫程式的某些方面。 設定網頁伺服器也可在這些資源上設定瀏覽器快取的標頭，以減少HTTP請求的數量，從而提高系統回應速度，如同作者所體驗的一樣。
同時工作的作者 authors-working-in-parallel
在作者環境中，同時工作的作者人數及其互動增加至系統的負載是主要限制因素。 因此，Adobe建議您根據共用的資料輸送量來擴充系統。
對於這種情況，Adobe在製作執行個體的雙節點shared-nothing叢集上執行基準測試。
-
基準測試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 hardware-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。
發佈環境特定的計算 publish-environment-specific-calculations
快取效率和流量 caching-efficiency-and-traffic
快取效率對網站速度至關重要。 下表顯示最佳化的AEM系統每秒可以使用反向Proxy （例如Dispatcher）處理多少頁面：
快取比率是Dispatcher無需存取AEM即可傳回的頁面百分比。 100%表示Dispatcher回答所有請求，0%表示AEM計算每個頁面。
範本和應用程式的複雜性 complexity-of-templates-and-applications
如果您使用複雜的範本，AEM需要更多時間才能呈現頁面。 從快取中取得的頁面不會受此影響，但在考慮整體回應時間時，頁面大小仍然相關。 轉譯複雜頁面通常比轉譯簡單頁面花費十倍的時間。
公式 formula
使用下列公式，您可以計算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
其他使用案例特定計算 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)，這會影響所選的部署。
請參閱