安裝與升級 > ThingWorx 大小設定指南 > 平台大小設定範例 > 範例 1：大量物件、少量內容和低寫入頻率
範例 1：大量物件、少量內容和低寫入頻率
情境
範例 1 的高層級情境概觀
監視整個區域中的 100,000 個泵。每個泵都會每五分鐘向 ThingWorx 報告 20 個內容值。在尖峰使用者存取期間，將會在一小時內由 1,000 個使用者呼叫 10 個混搭，每個都有 10 個服務。此 ThingWorx 組態使用 Microsoft SQL Server 資料庫。
需求
• 物件數 (T)：100,000 個物件
• 內容數 (P)：20 個內
• 寫入頻率 (FD)：每 5 分鐘，或每天 288 次寫入
• 尖峰使用期 (t)：1 小時，或 3600 秒
• 混搭數 (M)：10 個混搭
• 使用者數 (U)：1000 個使用者
• 每個混搭的服務數 (SM)：10 個服務
• 使用者載入每個混搭的次數 (LM)：2 次
計算
• 資料擷取：
WPS = T × [(P1 × F1)]
= 100,000 × [(20 × 288/86400)]
≈ 6,667 writes per second
* 
在此計算中，不需要總和，因為所有 20 個裝置內容都具有相同的寫入頻率。
我們也不要忘記計算連線伺服器值：
CS = T / 100,000
= 100,000 / 100,000
= 1 Connection Server
• 資料視覺化：
R = [(SM + 1) × UM × LM ] / t
= [(10 + 1) × 1000 × 2 ] / 3600
≈ 6.11 requests per second
我們可以只將每個混搭之所有使用者的 HTTP 請求 (透過 (SM + 1) x UM 得出) 乘以總混搭數 (M)，來求出此處的總和，這是因為每個混搭所預期的流量都相同，並假設包含相同的服務數。所以：
R = R1 × M
≈ 6.11 × 10 ≈ 61.1 HTTP Requests per second
條件比較
• T = 100,000 ->「中型」平台 (或更大平台，含 Microsoft SQL Server)
• CS = 1 -> 建議使用一個連線伺服器
• WPS = 6,667 ->「小型」平台 (或更大)
• R = 61 ->「中型」平台 (或更大)
大小設定
假設需要有「中型」ThingWorx 系統才能滿足所有條件，應根據代管類型來考慮下列大小設定：
大小
Azure VM
AWS EC2
CPU 核心
記憶體 (GiB)
ThingWorx Platform：中型
F16s v2
C5d.4xlarge
16
32
Microsoft SQL Server 資料庫：中型
F16s v2
C5d.4xlarge
16
32
ThingWorx Connection Server
F2s v2
C5d.large
2
4
請記得針對連線伺服器大小設定審核連線服務說明中心，其也使用本指南中的 T，但也會考慮諸如 Edge 請求 (包括 WebSocket)、內容更新、檔案傳輸與平均訊息大小等因素。
比較計算與觀察的結果
範例 1 模擬了「已連線產品解決方案」使用案例，較不著重於多樣化混搭，而更側重於連線至平台的物件數。在實際情況下，每個混搭的服務數以及存取每個混搭的使用者數 (如範例 2 所探究) 會有更大的差異。
從基礎結構的角度來看，平台執行地很好，平均為 51.6% 的 CPU 使用率及 5.3 GB 的記憶體耗用。MS SQL 平均為 16.7% 的 CPU 使用率及 13.9 GB 的記憶體。
從平台的角度來看，HTTP 請求率平均為每秒 62 次運算，符合預期的 61 OPS，而「值串流佇列」率在實際情況下可穩定保持在約 7k WPS，接近預期的 6.7k WPS 以上。
在正常操作中，SQL Server 一般會尋求使用盡可能多的記憶體。它會假設在專用電腦上，並將盡可能多的資料儲存在記憶體中。這可以在上述記憶體使用圖表中看到，且只會在接近測試結尾時保持平穩耗用，並保留一小部份給作業系統使用。
雖然此基礎結構在針對其執行的大小調整測試期間可以保持穩定，但建議在生產設定中使用之前進行較長的持續時間測試 (最好是在資料庫達到其預期資料保留層級之前)，以確保資料庫伺服器大小設定正確。
這是否有幫助?