示例 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
= 100,000 × [(20 × 288/86400)]
≈ 6,667 writes per second
 | 在此计算中，不需要求和，因为所有 20 个设备属性的写入频率相同。 |
切记还要计算连接服务器值：
CS = T / 100,000
= 100,000 / 100,000
= 1 Connection Server
= 100,000 / 100,000
= 1 Connection Server
• 数据可视化：
R = [(SM + 1) × UM × LM ] / t
= [(10 + 1) × 1000 × 2 ] / 3600
≈ 6.11 requests per second
= [(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
≈ 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 DB：中 | F16s v2 | C5d.4xlarge | 16 | 32 |
ThingWorx Connection Server | F2s v2 | C5d.large | 2 | 4 |
有关连接服务器大小设定，请参阅连接服务帮助中心，其中同样使用了本指南中的 T，但也考虑了 Edge 请求 (包括 websocket)、属性更新、文件传输和平均消息大小等因素。
比较计算结果和观察结果
示例 1 模拟了已连接产品解决方案用例，减少了对多样化混搭的关注，而将更多的注意力放在连接到平台的事物数上。在现实情景中，每个混搭的服务数和访问每个混搭的用户数 (如示例 2 所述) 差异巨大。
从基础设施的角度来看，平台性能较高，平均 CPU 利用率为 51.6%，内存消耗为 5.3 GB。MS SQL 的平均 CPU 利用率为 16.7%，内存消耗为 13.9 GB。
从平台的角度来看，HTTP 请求速率平均为每秒 62 个操作 (与预期的 61 个操作相符)，并且值流队列速率实际上稳定在 7k WPS 左右 (与上述的预期 6.7k WPS 接近)。
在正常操作中，SQL Server 通常会使用尽可能多的内存。假设它位于专用计算机上，并在内存中存储尽可能多的数据。这可以从上面的内存使用情况图表中看出，消耗仅在测试快结束时趋平，并为操作系统留下一个小池。
此基础结构在对其执行大小设定测试期间是稳定的，但是建议在生产设置中使用之前执行持续时间更长的测试 (理想情况下，直到数据库达到其预期数据保留级别)，以确保数据库服务器大小设定正确。