示例 2：几个事物、几个属性和高写入频率
情景
示例 2 高级情景概述
一家拥有 250 台监控计算机的中等规模工厂，每台计算机以不同的速率向 ThingWorx 发送 60 次属性更新 (请参阅“要求”)。
峰值使用时长为 30 分钟，在此期间，100 名用户可能对 5 个唯一混搭进行不同次数的调用，每个混搭具有不同数量的服务。此配置使用 PostgreSQL 数据库。
需求
• 事物数 (T)：250 个事物
• 属性数 (P，每个设备具有三个不同的属性组)：
P1 | P2 | P3 |
|---|---|---|
10 个属性 | 45 个属性 | 5 个属性 |
• 写入频率 (F)：
F1 | F2 | F3 |
|---|---|---|
每 30 秒 (2,880/天) | 每秒 (86,400/天) | 每小时 (24/天) |
• 峰值使用期间 (t) = 30 分钟或 1800 秒
• 混搭数 (M) = 5 个混搭
• 用户数 (UM)：
UM1 | UM2 | UM3 | UM4 | UM5 |
|---|---|---|---|---|
100 名用户 | 100 名用户 | 100 名用户 | 10 名用户 | 10 名用户 |
注：用户请求数较少的混搭是管理用户共有的 | ||||
• 每个混搭的服务数 (SM)：
SM1 | SM2 | SM3 | SM4 | SM5 |
|---|---|---|---|---|
20 个服务 | 4 服务 | 10 个服务 | 15 个服务 | 25 个服务 |
• 用户加载每个混搭的次数 (LM)：
LM1 | LM2 | LM3 | LM4 | LM5 |
|---|---|---|---|---|
30 次 | 30 次 | 30 次 | 1 次 | 1 次 |
注：30 次表示混搭 1、2 和 3 在 30 分钟的峰值期间 (可能通过自动刷新) 每分钟重新加载一次。 | ||||
计算
• 数据提取：
WPS = T × [(P1 × F1) + (P2 × F2) + (P3 × F3)]
= 250× [(10 × 1/30) + (45 × 1) + (5 × 1/3600)]
≈ 11,334 writes per second
= 250× [(10 × 1/30) + (45 × 1) + (5 × 1/3600)]
≈ 11,334 writes per second
这有点复杂，因为属性以不同的速率写入。切记如有必要，可将 FD 除以 86400，以将其转换为秒数。
还要记得计算 CS 值：
CS = T / 100,000
= 250/ 100,000
= 0.0025 Connection Servers
= 250/ 100,000
= 0.0025 Connection Servers
• 数据可视化：
R = [(SM + 1) × UM × LM ] / t
R1 = [(20 + 1) × 100 × 30 ] / 1800
≈ 35 requests per second
R2 = [(4 + 1) × 100 × 30 ] / 1800
≈ 8.33 requests per second
R3 = [(10 + 1) × 100 × 30 ] / 1800
≈ 18.33 requests per second
R4 = [(15 + 1) × 10 × 1 ] / 1800
≈ 0.09 requests per second
R5 = [(25 + 1) × 10 × 1 ] / 1800
≈ 0.14 requests per second
R = R1 + R2 + R3 + R4 + R5
≈ 61.89 requests per second
R1 = [(20 + 1) × 100 × 30 ] / 1800
≈ 35 requests per second
R2 = [(4 + 1) × 100 × 30 ] / 1800
≈ 8.33 requests per second
R3 = [(10 + 1) × 100 × 30 ] / 1800
≈ 18.33 requests per second
R4 = [(15 + 1) × 10 × 1 ] / 1800
≈ 0.09 requests per second
R5 = [(25 + 1) × 10 × 1 ] / 1800
≈ 0.14 requests per second
R = R1 + R2 + R3 + R4 + R5
≈ 61.89 requests per second
在此情景下，每个混搭具有不同数量的服务，而其中一些由少量用户调用。此外，一些混搭每分钟刷新一次，而另一些只能加载一次。
在这种情况下，一定不要忽略 LM。具有自动刷新的混搭的附加服务调用会对系统大小设定产生显著影响。
尽管此计算具有更多部分，但是如果针对每个混搭分解方程，然后使结果相加 (如上图所示)，则会变得非常简单。
条件比较
• T = 250 ->“特小”平台 (或更大，采用 PostgreSQL)
• CS = 0.0025 -> 不需要任何连接服务器
• WPS = 11,334 ->“小”平台大小 (或更大)
• R = 61.89 ->“中”平台大小 (或更大)
大小设定
假设“中”ThingWorx 系统需要满足所有条件，则应根据托管类型考虑以下大小设定：
大小 | Azure VM | AWS EC2 | CPU 内核 | 内存 (GiB) |
|---|---|---|---|---|
ThingWorx Platform：中 | F16s v2 | C5d.4xlarge | 16 | 32 |
PostgreSQL 数据库：中 | F16s v2 | C5d.4xlarge | 16 | 32 |
比较计算结果和观察结果
示例 2 模拟了具有多个混搭的实际应用程序，每个混搭以不同的刷新速率进行各种服务调用，以及模拟远程事物以各种速率将数据发送给平台。
从基础设施的角度来看，平台性能较高，平均 CPU 利用率为 34.8%，内存消耗为 3.1 GB。PostgreSQL 平均 CPU 利用率为 35.1%，内存消耗为 8.1 GB。
从平台的角度来看，HTTP 请求速率平均为每秒 63 个操作 (与预期的 62 个操作相符)，并且值流队列每秒写入次数实际上稳定在 12k WPS 左右 (与上述的预期 11.3k WPS 接近)。
示例 2 模拟部署的观察结果
从应用程序或用户的角度来看，设备或用户模拟器未发现错误、性能问题或错误的请求/响应。系统会及时处理所有新请求。
如上图所示，实施为模拟的稳态工作负载以及设备和/或用户活动中更真实的峰值留出了足够的资源。