資產效能指南

數位資產管理通常用於效能重要的情況;不過,一般的DAM設定包含許多可能影響效能的硬體和軟體元件。 本檔案提供下列內容:

  • 系統管理員關於為新的數字資產管理設定確定最佳硬體大小的資訊
  • 軟體開發人員若想疑難排解有效能問題的DAM例項,此資訊

效能問題

數位資產管理效能不佳,可能會透過三種方式影響使用者體驗:互動式效能、資產處理和下載速度。 為了改善效能,必須正確測量觀察到的效能並建立目標量度。

1. 互動式搜尋和瀏覽 使用者正在搜尋資產或瀏覽DAM Finder,並抱怨回應時間緩慢,或搜尋結果沒有立即顯示。 這是互動式效能問題。

互動式效能以頁面回應時間衡量。 這是從接收HTTP要求到關閉HTTP回應所花的時間,可從要求記錄檔中判斷。 一般目標效能是指低於兩秒的頁面回應時間。

2. 資產處理 資產處理問題是使用者上傳資產時,需要數分鐘的時間,直到資產輕鬆轉換並內嵌至AEM DAM。

資產處理效能以平均工作流程處理完成時間衡量。 這是從叫用資產更新工作流程程式到完成所需的時間,可從工作流程報表使用者介面決定。 一般目標效能取決於處理的資產大小和類型以及轉譯次數。 目標效能的範例如下:

  • 使用標準轉譯時,小於1280x1280像素的影像需低於10秒
  • 使用標準轉譯時,小於100 MB的影像需要1分鐘以下
  • 短於1分鐘的高清視頻剪輯不到5分鐘

3. 下載速度 從AEM DAM下載時,吞吐量問題會出現,且瀏覽DAM管理員或DAM Finder時,縮圖不會立即顯示。

吞吐量效能以每秒千比特的下載速率衡量。 一般100次同時下載的目標效能為每秒300千位。

4. 影響資產處理效能的因素

為了能夠估計處理資產所需的硬體,需要考慮以下方面:

  • 影像的解析度(像素)
  • 分配給AEM進程的堆

影像中包含的像素數量決定了處理時間 — 更多像素表示處理所花的時間較長。
影像類型、壓縮率或儲存影像的檔案的相關大小對整體效能沒有重大影響。

堆已被確定為最重要的限制因素。 每當資產超過可用可用記憶體時,處理效能就會迅速下降。

DAM流程非常適合大量並行執行。 以批次和多核處理器上傳資產,可加快每個資產的絕對逗留時間。

5. 評估執行資產處理的硬體需求

大量處理數字資產需要優化的硬體資源,最相關的因素是影像大小和處理後影像的峰值吞吐量。

分配至少16GB的堆並配置 DAM更新資產 要使用的工作流程 Camera Raw套件 用於擷取原始影像。

了解系統

一般的DAM設定包含透過負載平衡器存取DAM的一般使用者。 DAM例項可能是群集設定的一部分,每個DAM例項在物理機或虛擬機上的Java虛擬機進程中運行。 DAM儲存由RAID磁碟提供,在單機設定情況下,或在群集設定情況下由受管網路連接儲存提供。

下圖說明一些解決方案(如適用)可能存在的效能陷阱區域。

與最終用戶的網路連接 網路連線速度緩慢可能會造成輸送量問題,在某些情況下,還會造成延遲問題。 有時,使用者與ISP的連線速度緩慢,尤其是在內部網路中。 這表示網路拓撲不正確。

臨時檔案系統 本地檔案系統速度慢會導致交互效能問題,尤其是在搜索時,因為搜索索引儲存在本地磁碟上。 如果使用命令列處理程式,這可能另外造成資產處理問題。

AEM DAM Finder 在搜索中經常遇到的交互效能問題是由於同一實例上許多併發用戶或其他佔用CPU的進程導致的CPU利用率高。 從虛擬機移動到專用電腦,並確保電腦上沒有其他服務運行有助於提高效能。 如果由於資產處理和許多同時使用者而造成CPU負載高,Day建議新增其他叢集節點。

AEM DAM工作流程 資產擷取期間執行時間長的工作流程程式會造成資產處理效能問題。 視處理的資產類型而定,這可能表示CPU過度使用。 Day建議您減少系統上運行的其他進程數,並通過添加群集節點來增加可用CPU數。

NAS連接 與NAS的網路連接不良會導致交互效能問題,因為在資產處理期間訪問新節點的速度會因網路延遲而減慢。 此外,網路吞吐量緩慢會對吞吐量產生負面影響,但也會對資產處理效能造成負面影響,因為載入和儲存轉譯速度會放緩。

NAS中延遲和吞吐量不佳的原因通常是網路拓撲或其他服務過度利用NAS。

網路連接儲存 過度使用的網路連接儲存系統可能會造成一系列問題:

  • 磁碟空間不足是經常遇到的問題,可借由正確調整DAM專案大小而避免。
  • 高磁碟延遲會傳播到CRX的緩慢存取時間,並可能導致互動式效能問題。
  • 磁碟吞吐量低可能導致CQ5 DAM的效能低。

效能測試

對於每個DAM專案,請務必建立效能測試制度,以快速找出並解決瓶頸。 若要這麼做,請考量下列查核點:

  1. 使用JMeter進行端到端效能測試 — 模擬搜索和瀏覽會話示例以檢測交互效能問題。
  2. 使用JMeter的吞吐量和延遲測試 — 在客戶端電腦上運行可確保不存在與拓撲相關的問題。
  3. 標準化資產處理測試 — 擷取少量範例資產並測量時間。 這應包括外部工作流程整合。
  4. 監視每個群集節點的CPU、磁碟和記憶體利用率。
  5. CRX讀/寫效能診斷,以確定非處理相關問題。
  6. 監控從DAM群集到NAS的網路延遲和吞吐量。
  7. 如果可能,直接在NAS上測試讀寫效能以及磁碟延遲。

調整瓶頸

目前,專案已使用下列效能調整:

  • 選擇性產生轉譯:只會將條件新增至資產處理工作流程,以產生您需要的轉譯,如此一來,只會為選取的資產產生成本較高的轉譯。
  • 例項間的共用資料儲存:當磁碟空間不足時,這可以大大降低所需的磁碟空間量,而成本是配置工作的增加,並且丟失資料儲存的自動清理。

延伸閱讀

本頁內容