Assets 調整指南

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

磁碟

DataStore

調整所需的磁碟空間 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倍。

取得檔案

共用資料存放區

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

使用案例

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

缺點

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

單點故障

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

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

增加複雜性

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

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

績效考量

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

延遲性

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

節點儲存或文檔儲存

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

  • 資產中繼資料
  • 資產版本
  • 稽核記錄
  • 封存的作用中工作流程

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

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

取得檔案

網路

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

限制

調整實作規模時，請務必牢記系統限制。 如果建議的實作超過這些限制，請運用創意策略，例如將資產分割為多個 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，請參閱 上傳超大型資產的設定.

本頁內容