這些調整大小准則提供部署AEM專案所需硬體資源的近似值。 規模估計取決於項目的體系結構、解決方案的複雜性、預期流量和項目需求。 本指南可協助您判斷特定解決方案的硬體需求,或找出硬體需求的上限和下限估計值。
要考慮的基本因素有:
網路速度
計算速度
I/O效能
硬碟
記憶體
典型的AEM設定由作者和發佈環境組成。 這些環境對底層硬體大小和系統配置有不同的要求。 author environment和publish environment章節中介紹了這兩種環境的詳細注意事項。
在典型的項目設定中,您有幾個環境要在其上進行項目階段:
開發
環境開發新功能或進行重大變更。最佳實務是讓每位開發人員使用開發環境(通常是在個人系統上進行本機安裝)。
製作測試環
境若要驗證變更。測試環境的數量可能因專案需求而異(例如,針對QA、整合測試或使用者驗收測試分別進行)。
發佈測試
環境主要用於測試社交協作使用案例和/或作者與多個發佈例項之間的互動。
製作製作環境
讓作者編輯內容。
發佈生產環
境提供發佈內容。
此外,環境可能會有所不同,從執行AEM的單一伺服器系統和應用程式伺服器,到高度擴充的多伺服器、多CPU叢集例項集。 我們建議您針對每個生產系統使用個別的電腦,而且不要在這些電腦上執行其他應用程式。
以下各節提供如何計算硬體需求的指引,並考慮到各種因素。 對於大型系統,建議您對參考配置執行一組簡單的內部基準測試。
效能最佳化是一項基本工作,必須先執行,才能針對特定專案進行基準評估。 在執行任何基準測試並使用其結果進行任何硬體調整計算之前,請務必應用效能優化文檔中提供的建議。
高級使用案例的硬體規模要求必須基於項目的詳細效能評估。 需要卓越硬體資源的高級使用案例的特點包括:
所需的磁碟空間很大程度上取決於Web應用程式的卷和類型。 計算時應考慮:
在「聯機」和「離線、修訂清除」期間持續監視磁碟空間。 如果可用磁碟空間降至臨界值以下,則將取消該過程。 關鍵值是儲存庫當前磁碟佔用空間的25% ,且不可配置。 建議將磁碟的大小至少比儲存庫大小(包括估計的增長)大兩三倍。
考慮為資料冗餘設定獨立磁碟冗餘陣列(RAID,如RAID10)。
生產實例的臨時目錄應至少具有6 GB的可用空間。
AEM在虛擬化環境中運作良好,但可能有CPU或I/O等因素無法直接與物理硬體相等。 建議選擇較高的I/O速度(一般而言),因為這在大多數情況下都是關鍵因素。 對您的環境進行基準評估是必要的,以便精確瞭解所需的資源。
故障保護網站部署在至少兩個不同的系統上。 如果一個系統發生故障,另一個系統可以接管並因此補償系統故障。
當所有系統都在運行時,可提高計算效能。 這種附加效能不一定與群集節點的數量成線性關係,因為這種關係高度依賴於技術環境;有關詳細資訊,請參閱群集文檔。
根據具體Web項目的基本要求和具體使用案例,對需要多少簇節點進行估計:
為了進行基準測試,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硬體平台上執行,並具備下列組態:
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代表複雜應用程式,或介於以下兩者之間的值:
|
cacheRatio | 調度器快取中的頁數百分比。 如果所有頁面都來自快取,請使用1;如果每個頁面都由AEM計算,則使用0。 |
templateComplexicy | 使用1到10之間的值來表示範本的複雜性。 數字越高,表示範本越複雜,每頁平均10個元件的網站使用值1,頁面平均40個元件使用值5,平均100多個元件使用值10。 |
啟動 | 每小時平均啟動次數(將平均大小的頁面和資產從作者複製到發佈層)除以x,其中x是在系統上執行的啟動次數,對系統處理的其他任務沒有效能副作用。 您也可以預先定義悲觀的初始值,例如x = 100。 |
如果您有更複雜的網站,您還需要更強大的網頁伺服器,讓AEM能夠在可接受的時間內回應要求。
複雜性低於4:
4到8之間的複雜性:
複雜性高於8:
*除了JVM所需的記憶體外,還可為作業系統保留足夠的記憶體。
除了計算預設Web應用程式外,您可能需要針對下列使用案例考慮特定因素。 計算值將添加到預設計算中。
大量處理數位資產需要最佳化硬體資源,最相關的因素是影像大小和處理後影像的峰值吞吐量。
分配至少16GB的堆並配置「DAM更新資產」工作流程,以使用Camera Raw套件擷取原始影像。
較高的影像吞吐量意味著計算資源需要能夠跟上系統I/O的腳步,反之亦然。 例如,如果匯入影像來啟動工作流程,則透過WebDAV上傳許多影像可能會造成工作流程積壓。
對TarPM、資料儲存和搜索索引使用單獨的磁碟有助於優化系統I/O行為(但通常將搜索索引保持在本地是合理的)。
另請參閱資產效能指南。
在製作環境上使用AEM MSM時的資源耗用量,主要取決於特定的使用案例。 基本因素包括:
使用代表性內容摘錄來測試計畫的使用案例,可協助您提高對資源消耗的瞭解。 如果您以計畫的總處理能力來推算結果,則可評估AEM MSM所需的額外資源。
請同時考慮,如果AEM MSM使用案例所消耗的資源超過計畫,並行工作的作者將會察覺效能副作用。
包含AEM Communities功能(社群網站)的AEM網站在發佈環境中體驗到來自網站訪客(成員)的高層互動。
社群網站的大小考量取決於社群成員預期的互動,以及頁面內容的最佳效能是否更重要。
使用者產生的內容(UGC)提交的成員會與頁面內容分開儲存。 雖然AEM平台使用節點儲存區將網站內容從作者複製到發佈,但AEM Communities會針對從未複製的UGC使用單一的通用儲存區。
對於UGC儲存,必須選擇影響所選部署的儲存資源提供程式(SRP)。
請參閱