Пример 2. Несколько вещей, несколько свойств и высокая частота записи
Сценарий
Обзор сценария верхнего уровня для примера 2
Завод среднего размера, где каждая из 250 контролируемых машин отправляет 60 обновлений свойств в ThingWorx с различной частотой (см. требования).
Период пикового использования равен 30 минутам, в котором 100 пользователей могут делать разное число вызовов 5 уникальных мэшапов, каждый из которых имеет различное количество сервисов. Эта конфигурация использует базу данных PostgreSQL.
Требования
• Количество вещей (T): 250 вещей
• Число свойств (P, три различные группы свойств на каждом устройстве):
P1 | P2 | P3 |
|---|---|---|
10 свойств | 45 свойств | 5 свойств |
• Частота записи (F):
F1 | F2 | F3 |
|---|---|---|
каждые 30 секунд (2880 в день) | каждую секунду (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 на 86 400, чтобы при необходимости привести значение к секундам.
Не забудьте также рассчитать значение 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 | AWS EC2 | Ядра ЦП | Память (ГБ) |
|---|---|---|---|---|
ThingWorx Platform: средняя | F16s v2 | C5d.4xlarge | 16 | 32 |
БД PostgreSQL: средняя | F16s v2 | C5d.4xlarge | 16 | 32 |
Сравнение рассчитанных и наблюдаемых результатов
В примере 2 расчет имитирует фактическое приложение со многими мэшапами, выполняющими вызовы разных сервисов с различными частотами обновления, а также с моделированием отправки удаленными вещами данных в платформу с различными частотами.
С точки зрения инфраструктуры платформа выполняется хорошо при использовании в среднем 34,8 % ЦП и потреблении 3,1 ГБ памяти. Для PostgreSQL: использование в среднем 35,1 % ЦП и потребление 8,1 ГБ памяти.
С точки зрения платформы средняя частота HTTP-запросов (63 операции в секунду) согласуется с ожидаемым значением OPS 62, а скорость очереди потоков значений на практике стабильно держалась на уровне примерно 12 000 записей в секунду, близком к ожидаемому значению в 11 300 WPS.
Наблюдаемые результаты из моделируемого развертывания в примере 2
С точки зрения приложения или пользователя имитаторами устройств или пользователей не были замечены ошибки, проблемы с производительностью или ошибочные запросы/ответы. Все новые запросы были обработаны своевременно.
Как показано на приведенных выше диаграммах, в реализации имеется достаточно ресурсов для резервирования как для моделируемой стационарной рабочей нагрузки, так и для более реалистичных пиков в активности устройства и/или пользователей.