Assets 規模調整指南 assets-sizing-guide

調整Adobe Experience Manager Assets實作的環境大小時，務必確保在磁碟、CPU、記憶體、IO和網路吞吐量方面有足夠的可用資源。 若要調整其中許多資源的大小，必須了解有多少資產正在載入到系統中。 如果沒有更好的量度，您可以將現有程式庫的大小除以程式庫的年齡，以找出建立資產的速率。

磁碟 disk

DataStore datastore

調整資產實施所需的磁碟空間大小時，常會發生錯誤，即根據要擷取至系統的原始影像大小計算。 依預設， Experience Manager 除了原始影像外，還會建立三個轉譯，以用於轉譯 Experience Manager UI元素。 在先前的實作中，觀察到這些轉譯會假設的資產大小是擷取資產的兩倍。

除了現成可用的轉譯外，大部分使用者都會定義自訂轉譯。 除了轉譯外，「資產」還可讓您從常見的檔案類型(例如InDesign和Illustrator)擷取子資產。

最後，AEM版本設定功能會儲存版本記錄中資產的重複項目。 您可以經常設定要清除的版本。 但是，許多用戶選擇長時間保留系統中的版本，這會佔用更多的儲存空間。

考慮到這些因素，您需要一種方法來計算可接受的準確儲存空間以儲存用戶資產。

執行步驟1-9可協助您判斷下列項目：

您可以在網路規模試算表中指定這些數字，以決定資料存放區所需的總空間。 此外，它也是判斷維護資產版本或修改資產對 Experience Manager 磁碟增長。

填入工具中的範例資料說明執行上述步驟的重要性。 如果您僅根據要載入的原始影像來調整資料存放區的大小(1TB)，您可能已將存放庫大小低估了15倍。

取得檔案

共用資料存放區 shared-datastores

對於大型資料存放區，您可以透過網路連接硬碟上的共用檔案資料存放區或S3資料存放區來實作共用資料存放區。 在這種情況下，個別執行個體不需要維護二進位檔的復本。 此外，共用資料存放區可促進無二進位檔復寫，並有助於減少將資產複製至發佈環境或卸載例項的頻寬。

使用案例 use-cases

資料存放區可在主要製作執行個體和備用製作執行個體之間共用，以將更新備用執行個體與主要執行個體中所做變更所花費的時間減至最少。 Adobe建議在主要製作例項和卸載製作例項之間共用資料存放區，以減少工作流程卸載時的開銷。 您也可以在製作與發佈執行個體之間共用資料存放區，以將復寫期間的流量減至最少。

缺點 drawbacks

由於有些缺陷，因此不建議在所有情況下共用資料存放區。

單點故障 single-point-of-failure

有共用資料儲存，會在基礎架構中引入單點故障。 假設您的系統有一個製作和兩個發佈執行個體，每個都有自己的資料存放區。 如果其中任何一個崩潰，其他兩個仍然可以繼續運行。 但是，如果資料儲存被共用，則單個磁碟故障可能會破壞整個基礎架構。 因此，請務必維護共用資料存放區的備份，以便快速還原資料存放區。

更偏好將AWS S3服務部署至共用資料存放區，因為與一般磁碟架構相比，這可大幅降低失敗的機率。

增加複雜性 increased-complexity

共用資料儲存區也增加了操作的複雜性，例如垃圾收集。 通常，只需按一下即可啟動獨立資料儲存的垃圾收集。 但是，共用資料儲存區除了在單個節點上運行實際集合之外，還需要對使用資料儲存的每個成員執行標籤掃描操作。

對於AWS操作，實施單個中央位置（通過S3），而不是構建EBS卷的RAID陣列，可以顯著抵消系統的複雜性和操作風險。

績效考量 performance-concerns

共用資料存放區需要將二進位檔案儲存在所有執行個體之間共用的網路裝載驅動器上。 由於這些二進位檔是透過網路存取，因此系統效能會受到不利影響。 通過使用快速網路連接到快速磁碟陣列，可以部分減輕影響。 然而，這是個代價高昂的提議。 在AWS操作中，所有磁碟都是遠程磁碟，需要網路連接。 執行個體啟動或停止時，短暫的卷會丟失資料。

延遲性 latency

S3實作中的延遲是由背景寫入執行緒所引入。 備份過程必須考慮此延遲和任何卸載過程。 卸載工作開始時，S3資產可能不存在於S3中。 此外，備份時，Lucene索引可能仍不完整。 它適用於寫入S3資料存放區並從其他執行個體存取的任何時效檔案。

節點儲存/文檔儲存 node-store-document-store

由於以下資源消耗，很難獲得NodeStore或DocumentStore的精確大小調整圖：

因為二進位檔會儲存在資料存放區中，每個二進位檔都會佔用一些空間。 大多數儲存庫的大小都低於100GB。 但是，可能會有大到1 TB的儲存庫。 此外，要執行離線壓縮，需要在卷上有足夠的可用空間以在預壓縮版本旁邊重寫壓縮的儲存庫。 經驗法則是，將磁碟的大小調整為儲存庫預期大小的1.5倍。

對於儲存庫，使用IOPS級別大於3000的SSD或磁碟。 要消除IOPS引入效能瓶頸的機會，請監視CPU IO等待級別以發現問題的早期跡象。

取得檔案

網路 network

Assets 有許多使用案例使網路效能比 Experience Manager 專案。 客戶可以擁有快速的伺服器，但如果網路連線不足以支援從系統上傳和下載資產的使用者載入，則速度仍會緩慢。 在確定用戶的網路連接中的阻塞點時，有一種良好的方法 Experience Manager at Experience Manager 用戶體驗、實例大小、工作流評估和網路拓撲的資產考量.

WebDAV webdav

如果您新增 Experience Manager 案頭應用程式的組合，網路問題變得更加嚴重，因為WebDAV協定效率低下。

為了說明這些低效性，Adobe在OS X上使用WebDAV測試了系統效能。開啟、編輯了3.5MB的InDesign檔案，並保存了更改。 有以下意見：

在分析WebDAV上檔案的平均保存時間時，發現效能會隨著頻寬的增加而顯著提高，直到達到5-10Mbps級別。 因此，Adobe建議同時訪問系統的每個用戶至少應具有10Mbps的上載速度和5-10Mbps的頻寬。

如需詳細資訊，請參閱 疑難排解 Experience Manager 案頭應用程式.

限制 limitations

調整實作規模時，請務必牢記系統限制。 如果建議的實作超過這些限制，請運用創意策略，例如在多個Assets實作間分割資產。

檔案大小不是導致記憶體不足(OOM)問題的唯一因素。 也取決於影像的尺寸。 在啟動AEM時提供較高的堆大小，可以避免OOM問題。

此外，您也可以編輯 com.day.cq.dam.commons.handler.StandardImageHandler 元件，以使用大於零的中間臨時檔案。

資產數上限 maximum-number-of-assets

由於檔案系統限制，資料儲存中可能存在的檔案數量限制可能為21億。 在達到資料存放區限制之前，儲存庫很可能會因為節點數過多而遇到問題。

如果轉譯錯誤產生，請使用Camera Raw程式庫。 但是，在此情況下，影像的最長邊不應大於65000像素。 此外，影像不應包含超過512 MP(512 *1024*1024像素)」。 資產規模無關緊要.

很難準確估計TIFF檔案的大小，該檔案支援的現成可用(OOTB)具有特定堆 Experience Manager 因為像素大小等其他因素會影響處理。 有可能 Experience Manager 可以處理大小為255 MB OOTB的檔案，但無法處理大小為18 MB的檔案，因為後者包含的像素比前者要高得多。

資產規模 size-of-assets

依預設， Experience Manager 可讓您上傳檔案大小高達2 GB的資產。 若要在AEM中上傳超大型資產，請參閱 上傳超大型資產的設定.