行銷活動：批次傳遞輸送量低於預期
批次電子郵件傳送的傳送速度可能比預期慢，即使傳送基礎結構中沒有功能缺陷亦然。 在此模式中，不會封鎖傳送，但實現的傳送率會下降，因為電子郵件內容太大，無法以預期的輸送量處理可用的傳送容量。
說明 description
已報告傳送相對於其預期每小時傳送目標表現不佳。 預期的傳送速率為每小時2000萬封電子郵件。 測試顯示，一小時內最多可傳送約1,300萬封電子郵件。
初始檢閱未顯示持續性平台失敗。
傳遞準備已記錄：
警告：傳遞內容的大小超過200.0 kB (227.2 kB)。
解決方法 resolution
後續追蹤分析顯示，主要原因是電子郵件內容的大小，其遠高於最佳實務指引。
後續測試中，當內容大小減少時，輸送量會大幅改善。 這確認問題主要與訊息大小和處理成本有關，而非一般平台中斷。
為什麼電子郵件大小會影響傳送速度？
電子郵件大小會直接影響輸送量，因為每封郵件都必須：
- 為收件者組裝，
- 已處理以進行個人化和追蹤，
- 準備傳輸，
- 已簽署並封裝以遞送，
- 已透過網路傳輸。
隨著HTML裝載增加，上述每個步驟的成本都會提高。
在高容量批次傳送中，此成本會乘以數百萬封訊息。 即使系統保持健康狀態，大型訊息仍會消耗傳送層級更多CPU和網路頻寬。 這些資源飽和後，系統仍可成功傳送，但每小時訊息數會下降。
為什麼會發生此情況？
大型電子郵件傳送緩慢的最常見原因是：
- 每個收件者必須傳輸更多位元組。 較大的訊息需要更多的傳出網路傳輸。 在規模上，這本身就可能成為一個限制因素。
- 每則訊息需要更多處理。 較大的HTML主體可增加內容裝配、個人化、追蹤連結處理和訊息封裝所需的工作。
- 傳送層級會更早達到資源限制。 當CPU或輸出頻寬完全被使用時，輸送量就會停止上升。 這並不一定表示發生故障；這可能只是表示基礎建設正在以目前訊息大小的完整容量運作。
- 範本設計可能會意外膨脹大小。 過多的標籤或過於複雜的個人化可能會增加演算後的訊息大小，使其遠遠超過編寫期間所顯示的範圍。
如果每則訊息的大小超過200kB，且使用2個中間來源伺服器（每個包含2個伺服器容器），則在傳送期間會發現：
全部4個（使用者空間 — 訊息元件/DKIM）都可使用CPU 100%
網路210 MB/s TX （4個容器各850 MB/s）
記憶體已使用35%，交換0，iowait 0%
速度達17.6米/小時
iowait 0和記憶體31%表示沒有任何東西被餓死或卡住。 100%的CPU表示MID層級是作用中的瓶頸，而且已完全使用，而這正是輸送量測試推動它達到的目標。 100% CPU唯一代表的是，CPU沒有多餘的空間，因此更輕的電子郵件或更多MID核心/容器可提供更高的輸送量或利潤。
Adobe的最佳實務是將電子郵件維持在35 kB左右 — https://experienceleague.adobe.com/zh-hant/docs/campaign/campaign-v8/send/delivery-best-practices