Assets大小調整指南 assets-sizing-guide
在調整Adobe Experience Manager Assets實作的環境大小時，請務必確保有足夠的可用資源，例如磁碟、CPU、記憶體、IO和網路傳輸量。 調整其中許多資源的大小需要瞭解載入系統的資產數量。 如果沒有更好的量度，您可以除以現有程式庫的大小，以找出建立資產的速率。
磁碟 disk
資料存放區 datastore
調整Assets實作所需磁碟空間大小的常見錯誤，是依據要擷取到系統中的原始影像大小進行計算。 根據預設，Experience Manager除了原始影像之外，還會建立三個轉譯，以用於轉譯Experience Manager使用者介面元素。 在先前的實施中，已觀察到這些轉譯假設是擷取的資產大小的兩倍。
除了現成可用的轉譯，大部分使用者還會定義自訂轉譯。 除了轉譯之外，Assets還可讓您從常見的檔案型別（例如Adobe InDesign和Adobe Illustrator）擷取子資產。
最後，Experience Manager的版本設定功能會在版本記錄中儲存資產的重複專案。 您可以設定要經常清除的版本。 然而，許多使用者選擇將版本保留在系統中很長時間，這會消耗額外的儲存空間。
考量這些因素，您需要一種方法來計算儲存使用者資產，且儲存空間精確到可以接受的程度。
- 決定載入系統的資產大小和數量。
- 取得要上傳至Experience Manager的資產代表性範例。 例如，如果您計畫將PSD、JPG、AI和PDF檔案載入系統，則需要每種檔案格式的多個範例影像。 此外，這些範例應能代表不同檔案大小和影像的複雜程度。
- 定義要使用的轉譯。
- 使用ImageMagick或Adobe Creative Cloud應用程式在Experience Manager中建立轉譯。 除了使用者指定的轉譯外，請建立立即可用的轉譯。 對於實作Dynamic Media的使用者，您可以使用IC二進位檔來產生PTIFF轉譯，以儲存在Experience Manager中。
- 如果您打算使用子資產，請針對適當的檔案型別產生子資產。
- 比較輸出影像、轉譯和子資產與原始影像的大小。 它可讓您在系統載入時產生預期的成長因子。 例如，如果您在處理1 GB資產後產生合併大小為3 GB的轉譯和子資產，轉譯成長係數為3。
- 決定要在系統中維護哪些資產版本的最長時間。
- 決定系統中修改現有資產的頻率。 如果將Experience Manager用作創意工作流程中的共同作業中樞，則變更量會很大。 如果僅將完成的資產上傳到系統，則此數字會低很多。
- 決定每月載入系統的資產數量。 如果您不確定，請確定目前可用的資產數量，然後將該數量除以最舊資產的年齡，即可計算大致數字。
執行上述步驟可協助您判斷下列專案：
- 要載入的資產原始大小。
- 要載入的資產數目。
- 轉譯成長因數。
- 每月進行的資產修改次數。
- 維護資產版本的月數。
- 每月載入的新資產數目。
- 儲存空間配置的成長年份。
您可以在網路大小調整試算表中指定這些數字，以決定資料存放區所需的總空間。 此外，它還是判斷在Experience Manager中維護資產版本或修改資產對磁碟成長的影響的實用工具。
工具中填入的範例資料說明了執行上述步驟的重要性。 如果您僅根據載入的原始影像來調整資料存放區的大小(1 TB)，您可能會將存放庫大小低估了15倍。
共用資料存放區 shared-datastores
對於大型資料存放區，您可以透過網路附加磁碟機上的共用檔案資料存放區或Amazon S3資料存放區來實作共用資料存放區。 在這種情況下，個別執行個體不需要維護二進位檔的復本。 此外，共用資料存放區有助於進行無二進位檔的複製，且有助於減少將資產複製到發佈環境所使用的頻寬。
使用案例 use-cases
資料存放區可在主要和待命製作執行個體之間共用，以將透過在主要執行個體中進行的變更更新待命執行個體所需的時間減至最少。 您也可以在製作和發佈執行個體之間共用資料存放區，以將復寫期間的流量降至最低。
缺點 drawbacks
由於某些缺陷，不建議在所有情況下共用資料存放區。
單一失敗點 single-point-of-failure
擁有共用資料存放區，會導致基礎架構出現單一故障點。 假設您的系統有一個作者和兩個發佈例項，每個例項都有自己的資料存放區。 如果其中任何一個當機，其他兩個仍可繼續執行。 但是，如果資料存放區是共用的，單一磁碟故障可能會毀掉整個基礎架構。 因此，請務必維持共用資料存放區的備份，以便快速還原資料存放區。
建議將AWS S3服務部署至共用資料存放區，因為相較於一般磁碟架構，此服務可大幅降低失敗的可能性。
增加複雜性 increased-complexity
共用資料存放區也會增加操作的複雜性，例如記憶體回收。 通常，只需按一下即可起始獨立資料存放區的記憶體回收。 不過，共用資料存放區除了在單一節點上執行實際收集之外，還需要對使用該資料存放區的每個成員執行標籤清除作業。
針對AWS作業，實作單一中央位置(透過Amazon S3)而非建置EBS磁碟區的RAID陣列，可大幅降低系統的複雜性和作業風險。
效能考量 performance-concerns
共用資料存放區要求二進位檔必須儲存在網路掛載的磁碟機上，而且所有執行個體之間必須共用。 由於這些二進位檔是透過網路存取，因此系統效能會受到不利的影響。 您可以使用快速網路連線到快速磁碟陣列，部分減輕影響。 不過，這是一項昂貴的提議。 如果有AWS作業，所有磁碟都是遠端磁碟，而且需要網路連線。 執行個體啟動或停止時，臨時磁碟區會遺失資料。
延遲 latency
S3實施中的延遲是由背景寫入對話串所引入。 備份程式必須解決這個延遲。 此外，進行備份時，Lucene索引可能會維持不完整。 它適用於寫入S3資料存放區並從其他執行個體存取的任何時間敏感型檔案。
節點存放區或檔案存放區 node-store-document-store
由於下列資源耗用，很難得出NodeStore或DocumentStore的精確大小數字：
- 資產中繼資料
- 資產版本
- 稽核記錄
- 已封存及使用中的工作流程
因為二進位檔儲存在資料存放區中，所以每個二進位檔都會佔用一些空間。 大部分的存放庫大小都低於100GB。 不過，可能有更大的存放庫大小最多為1 TB。 此外，若要執行離線壓縮，您需要磁碟區有足夠的可用空間，以便與預先壓縮的版本一起重寫壓縮的存放庫。 一個好的經驗法則是將磁碟大小調整為存放庫預期大小的1.5倍。
對於存放庫，請使用IOPS等級大於3000的SSD或磁碟。 為了避免IOPS造成效能瓶頸，請監控CPU IO Wait等級，以找出問題的早期跡象。
網路 network
Assets有數個使用案例，讓網路效能比我們的Experience Manager專案中的許多效能更重要。 客戶可以擁有快速伺服器，但如果網路連線不夠大，無法支援從系統上傳和下載資產的使用者負載，則速度仍會顯得緩慢。 在Assets考量使用者體驗、執行個體大小調整、工作流程評估及網路拓撲時，判斷使用者與Experience Manager的網路連線中的扼殺點的方法很好。
限制 limitations
在調整實作規模時，請務必牢記系統限制。 如果建議的實作超過這些限制，請採用創意策略，例如跨多個Assets實作分割資產。
檔案大小並非造成記憶體不足(OOM)問題的唯一因素。 這也取決於影像的尺寸。 當您啟動Experience Manager時，提供較大的棧積大小可避免OOM問題。
此外，您可以在Configuration Manager中編輯com.day.cq.dam.commons.handler.StandardImageHandler元件的臨界值大小屬性，以使用大於零的中繼暫存檔案。
資產數量上限 maximum-number-of-assets
由於檔案系統的限制，資料存放區中可以存在的檔案數量限製為21億。 存放庫可能會因為在達到資料存放區限制之前很久就因為大量節點而遇到問題。
如果轉譯的產生不正確，請使用Camera Raw程式庫。 不過，在此情況下，影像的最長邊不應大於65000畫素。 此外，影像不應包含超過512 MP （512 x 1024 x 1024畫素）。 資產的大小並不重要。
由於其他因素（例如畫素大小）會影響處理，因此很難準確估計受Experience Manager之特定棧集支援的現成可用TIFF檔案的大小。 Experience Manager可能可以立即處理大小為255 MB的檔案，但無法處理大小為18 MB的檔案，因為後者的畫素數目異常高於前者。
資產大小 size-of-assets
根據預設，Experience Manager可讓您上傳檔案大小最大為2 GB的資產。 若要在Experience Manager中上傳非常大的資產，請參閱要上傳非常大資產的設定。