多工作階段建議

在多工作階段環境中決定執行個體上的使用者工作階段數目上限時，您應該考慮幾個因素，以確保獲得最佳效能和串流體驗。以下是決定執行個體上最佳使用者工作階段數目的建議：

• 評估資源需求：了解工作階段內要使用的應用程式的資源需求。考量因素包括 CPU、記憶體、磁碟 I/O 和網路頻寬等。此評估將有助於確定每個使用者工作階段通常需要的資源數量。

• 考慮執行個體規格：考慮執行個體的規格，包括 CPU 數量、可用記憶體和 GPU 規格。規格較高的執行個體可以處理較多的使用者工作階段數。如需 AppStream 2.0 支援的不同執行個體類型和定價的詳細資訊，請參閱 Amazon AppStream 2.0 定價。

• 效能測試：對預期在使用者工作階段內執行的應用程式和工作負載進行效能測試。測量資源使用率、回應時間和整體系統效能。使用此資料來評估並行使用者工作階段對效能的影響，並決定最佳 session-to-instance 比例。您可以針對 AppStream 2.0 提供的不同執行個體類型執行這些評估，找出最適合使用者的執行個體類型或大小。如需 AppStream 2.0 提供的不同執行個體類型的詳細資訊，請參閱AppStream 2.0 執行個體系列。

• 監控資源使用率：在正常使用期間，持續監控執行個體的資源使用率。觀察 CPU、記憶體和磁碟使用率。確保資源使用率維持在可接受的限制範圍內，以避免效能降低。對於多工作階段環境，您可以在 AppStream 2.0 和 CloudWatch 主控台上檢視這些指標。如需詳細資訊，請參閱 監控 Amazon AppStream 2.0 資源。

• 考慮使用者行為模式：分析使用者行為模式，以了解尖峰使用期和可能的並行使用量。有些使用者可能屬於間歇或零星的使用模式，有些使用者則可能一整天保持一致的使用情形. 在決定使用者工作階段數目上限時，請將這些模式納入考量，以免在尖峰期間發生資源爭用。

  AppStream 2.0 可讓您設定每個執行個體最多 50 個使用者工作階段，無論您選擇的執行個體類型或大小為何。不過，這只是上限，而不是建議的限制。下列範例資料表可協助您決定多工作階段機群中，執行個體上的使用者工作階段數目上限。資料表中列出的建議使用者人數上限是根據一般準則和假設而定。務必使用實際工作負載進行測試，因為實際效能會因工作負載的個別特性、應用程式的資源需求和使用者行為而有所不同。

根據工作負載類型的建議
最終使用者類別	工作負載類型	範例使用者	使用案例	建議組態
執行單一任務並使用最少應用程式的最終使用者	光線	任務工作者、服務台使用者	資料輸入應用程式、文字編輯、堡壘主機	每個 vCPU 在串流上有 4 個使用者。標準擴大 /2 倍大或串流。
執行單一任務並使用最少應用程式的最終使用者	輕量至中等	任務工作者、服務台使用者、聯絡中心員工	資料輸入應用程式、文字編輯、堡壘主機、聊天、電子郵件、傳訊應用程式	每個 vCPU 在串流上有 2 個使用者。標準擴大 /2 倍大或串流。
建立複雜試算表、簡報和大型文件的最終使用者	中	任務工作者、聯絡中心員工、業務分析師	資料輸入應用程式, 聊天、電子郵件、傳訊應用程式、生產力應用程式	Stream.memory.xlarge+ 或 Stream.compute.xlarge+ 上每個 vCPU 2 個使用者
具有高效能工作負載的最終使用者	中等到繁重	知識工作者、軟體開發人員、商業智慧分析師	軟體指令碼	Stream.memory.xlarge+ 或 Stream.compute.xlarge+ 上每個 vCPU 1 個使用者
具有高效能工作負載的最終使用者	繁重	知識工作者、軟體開發人員、資料科學家	屏幕共享，數據分析，音頻會議	串流上每 2 個 vCPUs 有 1 個使用者。記憶體擴充 + 或串流。
最終使用者的工作負載需要圖形與大量運算/記憶體資源	繁重到加速	圖形/架構設計師、CAD/CAM 使用者	音訊會議、圖形密集型應用程式，例如遠端圖形工作站	每 2 個 vCPUs 顯示卡可提供 1 個使用者。 *
最終使用者的工作負載需要圖形與大量運算/記憶體資源	加速	視訊編輯器、遊戲玩家和遊戲開發人員、資料礦工、GIS 資料工程師、AI 科學家	音訊會議、視訊轉碼與 3D 渲染、相片擬真設計、繪圖工作站、ML 模型訓練、ML 推論	每 2 個 vCPUs 顯示卡可提供 1 個使用者。G5. *