Assets 定尺

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

磁碟

資料儲存

調整所需磁碟空間大小時出現的常見錯誤 Assets 實現是根據要被攝取到系統中的原始影像的大小來計算。 預設情況下， Experience Manager 除了原始影像外，還建立了三個格式副本，以用於呈現 Experience Manager 用戶介面元素。 在以前的實施中，已觀察到這些格式副本假定的資產大小是所接收資產的兩倍。

除了現成格式副本外，大多數用戶還定義自定義格式副本。 除了格式副本， Assets 允許您從常用檔案類型中提取子資產，例如 Adobe InDesign 和 Adobe Illustrator。

最後，版本控制功能 Experience Manager 儲存版本歷史記錄中的資產副本。 您可以配置要經常清除的版本。 但是，許多用戶選擇在系統中長時間保留版本，這會消耗額外的儲存空間。

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

  1. 確定要載入到系統中的資產的大小和數量。
  2. 獲取要上載到的資產的代表性示例 Experience Manager。 例如，如果您計畫將PSD、JPG、AI和PDF檔案載入到系統中，則需要每個檔案格式的多個示例影像。 此外，這些示例應代表不同的檔案大小和影像的複雜性。
  3. 定義要使用的格式副本。
  4. 在中建立格式副本 Experience Manager 使用 ImageMagick 或 Adobe Creative Cloud 應用程式。 除了用戶指定的格式副本外，還可建立現成的格式副本。 對於實施Dynamic Media的用戶，可以使用IC二進位檔案生成要儲存在Experience Manager中的PTIFF格式副本。
  5. 如果計畫使用子組，請為相應的檔案類型生成它們。
  6. 將輸出影像、格式副本和子組的大小與原始影像進行比較。 它允許您在載入系統時生成預期的增長因子。 例如，如果在處理1 GB的資產後生成合併大小為3 GB的格式副本和子元件，則格式副本增長系數為3。
  7. 確定在系統中維護資產版本的最長時間。
  8. 確定系統中修改現有資產的頻率。 如果 Experience Manager 在創意工作流中用作協作中心，更改量很大。 如果只將完成的資產上載到系統，則此數字要低得多。
  9. 確定每月載入到系統中的資產數。 如果您不確定，請確定當前可用的資產數量，並將該數量除以最舊資產的年齡，以計算大致數量。

執行上述步驟可幫助您確定以下內容：

  • 要載入的資產的原始大小。
  • 要載入的資產數。
  • 格式副本增長因子。
  • 每月進行的資產修改數。
  • 維護資產版本的月數。
  • 每月載入的新資產數。
  • 儲存空間分配的年增長。

您可以在「網路規模」電子錶格中指定這些數字，以確定資料儲存所需的總空間。 此外，它還是確定在中維護資產版本或修改資產的影響的有用工具 Experience Manager 磁碟增長。

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

取得檔案

共用資料儲存

對於大型資料儲存，您可以通過網路連接驅動器上的共用檔案資料儲存或通過AmazonS3資料儲存來實現共用資料儲存。 在這種情況下，單個實例不需要維護二進位檔案的副本。 此外，共用資料儲存有助於無二進位複製，並有助於減少將資產複製到發佈環境的頻寬。

使用案例

資料儲存可以在主實例和備用作者實例之間共用，以最小化在主實例中所做的更改更新備用實例所花費的時間。 您還可以在作者和發佈實例之間共用資料儲存，以最大限度地減少複製過程中的流量。

缺陷

由於某些缺陷，不建議在所有情況下共用資料儲存。

單點故障

擁有共用資料儲存，在基礎架構中引入單點故障。 假設您的系統有一個作者和兩個發佈實例，每個實例都有自己的資料儲存。 如果其中任何一個崩潰，其他兩個仍然可以繼續運行。 但是，如果共用資料儲存，則單個磁碟故障可能會導致整個基礎架構崩潰。 因此，請確保維護共用資料儲存的備份，從中可以快速恢復資料儲存。

為共用資料儲存部署AWSS3服務是首選，因為與普通磁碟體系結構相比，它顯著降低了故障的可能性。

增加複雜性

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

對於AWS業務，實施單個中心位置(通過AmazonS3)，而不是構建EBS卷的RAID陣列，可以大大抵消系統的複雜性和操作風險。

效能問題

共用資料儲存要求將二進位檔案儲存在所有實例之間共用的網路裝載驅動器上。 由於這些二進位檔案是通過網路訪問的，因此系統效能會受到負面影響。 通過使用快速網路連接到快速磁碟陣列，可以部分減輕影響。 然而，這是個昂貴的提議。 在AWS操作中，所有磁碟都是遠程的，需要網路連接。 當實例啟動或停止時，臨時卷丟失資料。

延遲

S3實現中的延遲由後台寫入線程引入。 備份過程必須考慮此延遲。 此外，在進行備份時， Lucene索引可能仍不完整。 它適用於寫入S3資料儲存並從另一個實例訪問的任何時間敏感檔案。

節點儲存或文檔儲存

很難為NodeStore或DocumentStore精確確定大小，因為以下資源佔用了資源：

  • 資產元資料
  • 資產版本
  • 審核日誌
  • 存檔和活動的工作流

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

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

取得檔案

網路

Assets 有許多使用案例使網路效能比我們的許多 Experience Manager 項目。 客戶可以擁有快速伺服器，但如果網路連接不夠大，無法支援從系統上載和下載資產的用戶的負載，則仍然會顯得很慢。 在用戶到的網路連接中確定扼流點的方法很好 Experience Manager 在 用戶體驗、實例規模、工作流評估和網路拓撲的資產考慮事項。

限制

在確定實施規模時，必須牢記系統限制。 如果建議的實施超出這些限制，則採用創新策略，例如跨多個資產分區 Assets 實現。

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

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

最大資產數

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

如果格式副本生成不正確，請使用Camera Raw庫。 但是，在這種情況下，影像的最長邊不應大於65000像素。 此外，影像不應超過512 MP（512 x 1024 x 1024像素）。 資產規模無關緊要。

很難準確估計支援的TIFF檔案的大小，該檔案的出廠時帶有特定堆 Experience Manager 因為像素大小等附加因素影響處理。 有可能 Experience Manager 可以處理255 MB的出廠設定檔案，但無法處理18 MB的檔案，因為後者包含的像素數比前者高得異乎尋常。

資產大小

預設情況下， Experience Manager 允許您上載檔案大小高達2 GB的資產。 在中上載非常大的資產 Experience Manager，請參閱 要上載超大資產的配置。

本頁內容