Ejemplo 1: Muchas cosas, pocas propiedades y frecuencia de escritura baja
Escenario
Resumen del escenario de nivel superior del ejemplo 1
Supervisión de 100.000 bombas por todo el área. Cada bomba informa de 20 valores de propiedades a ThingWorx cada cinco minutos. Durante el pico de accesos de usuario, 1.000 usuarios llamarán a 10 mashups, cada uno con 10 servicios, en una hora. En esta configuración de ThingWorx se utiliza una base de datos de Microsoft SQL Server.
Requisitos
• Número de cosas (T): 100.000 cosas
• Número de propiedades (P): 20 propiedades
• Frecuencia de escritura (FD): cada 5 minutos o 288 escrituras por día
• Período pico de uso (t): 1 hora o 3.600 segundos
• Número de mashups (M): 10 mashups
• Número de usuarios (U): 1.000 usuarios
• Número de servicios por mashup (SM): 10 servicios
• Número de veces que los usuarios cargan cada mashup (LM): 2 veces
Cálculos
• Ingesta de datos:
WPS = T × [(P1 × F1)]
= 100,000 × [(20 × 288/86400)]
≈ 6,667 writes per second
= 100,000 × [(20 × 288/86400)]
≈ 6,667 writes per second
 | En este cálculo, no se requiere una suma, ya que las 20 propiedades del dispositivo tienen la misma frecuencia de escritura. |
No se olvide de calcular también el valor del servidor de conexión:
CS = T / 100,000
= 100,000 / 100,000
= 1 Connection Server
= 100,000 / 100,000
= 1 Connection Server
• Visualización de datos:
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
Para resolver la suma aquí, se pueden multiplicar las solicitudes HTTP de todos los usuarios por mashup (proporcionadas por (SM + 1) x UM) por el número total de mashups (M), porque cada mashup espera la misma cantidad de tráfico y se supone que contiene el mismo número de servicios. Por lo tanto:
R = R1 × M
≈ 6.11 × 10 ≈ 61.1 HTTP Requests per second
≈ 6.11 × 10 ≈ 61.1 HTTP Requests per second
Comparación de criterios
• T = 100.000 -> plataforma "mediana" (o mayor, con Microsoft SQL Server)
• CS = 1 -> un servidor de conexión recomendado
• WPS = 6.667 -> plataforma "pequeña" (o mayor)
• R = 61 -> plataforma "mediana" (o mayor)
Tamaño
Dado que se necesita un sistema ThingWorx "mediano" para satisfacer todos los criterios, se debe tener en cuenta el siguiente tamaño, según el tipo de hosting:
Tamaño | Máquina virtual de Azure | EC2 de AWS | Núcleos de CPU | Memoria (GiB) |
|---|---|---|---|---|
ThingWorx Platform: mediana | F16s v2 | C5d.4xlarge | 16 | 32 |
Base de datos de Microsoft SQL Server: mediana | F16s v2 | C5d.4xlarge | 16 | 32 |
ThingWorx Connection Server | F2s v2 | C5d.large | 2 | 4 |
Recuerde consultar el centro de ayuda de Connection Services para obtener el tamaño de Connection Server, que utiliza T de este manual, pero también tiene en cuenta factores como, por ejemplo, las solicitudes periféricas (entre las que se incluye WebSockets), las actualizaciones de propiedades, las transferencias de ficheros y el tamaño medio de los mensajes.
Comparación de los resultados calculados y observados
En el ejemplo 1 se simula un caso de uso de la solución de productos conectados, con menos foco en los diversos mashups y más centrado en el número de cosas conectadas a la plataforma. En un escenario real, hay mayores variaciones tanto en el número de servicios por mashup como en el número de usuarios que acceden a cada mashup (como se explora en el ejemplo 2).
Desde el punto de vista de la infraestructura, la plataforma se ha ejecutado correctamente, con un promedio del 51,6 % de uso de CPU y 5,3 GB de memoria. MS SQL presentó un promedio del 16,7 % de uso de CPU y 13,9 GB de memoria.
Desde el punto de vista de la plataforma, el promedio de velocidad de solicitudes HTTP fue de 62 operaciones por segundo, en línea con las 61 operaciones esperadas y la velocidad de cola de flujo de valor fue estable alrededor de 7.000 WPS en la práctica: cerca de las 6.700 WPS esperadas.
Durante el funcionamiento normal, SQL Server suele intentar utilizar tanta memoria como pueda. Se supone que se encuentra en un ordenador dedicado y que almacena tantos datos en la memoria como sea posible. Esto se puede ver en el gráfico de uso de memoria anterior, con la redistribución del consumo solo cerca del final de la prueba, con un pequeño grupo que se deja para el sistema operativo.
Aunque esta infraestructura es estable durante las pruebas de tamaño que se realizan en ella, se recomienda realizar una prueba de duración más larga (idealmente hasta que la base de datos alcance los niveles de retención de datos esperados) antes de su utilización en una configuración de producción para asegurarse de que el servidor de la base de datos tenga un tamaño adecuado.