Visualización de datos
Requisitos del sistema para el enfoque de visualización en la carga del servidor generada a partir de experiencias de usuario (mashups) dentro de la aplicación de negocio.
De manera similar a la ingesta, la carga desde la visualización depende no solo del número de mashups, sino también de la complejidad de cada mashup y del número de usuarios simultáneos que se espera que tengan acceso a ellos.
|
t
|
Período de tiempo de pico de acceso de usuarios: período de tiempo durante el que se llama a los siguientes mashups y servicios (en segundos).
|
|
M
|
Mashups únicos: número de mashups únicos a los que se espera que los usuarios accedan durante ese tiempo.
|
|
SM
|
Servicios por mashup: para cada mashup único, se determina el número de servicios a los que se llama.
|
|
UM
|
Número de usuarios simultáneos: el número total de usuarios que se espera que utilicen estos mashups a la vez durante este período de tiempo.
|
|
LM
|
Número de veces que los usuarios cargan cada mashup: el número de veces que se espera que cada usuario individual acceda a ese mashup durante el período de tiempo.
En general, siempre será al menos uno, pero se debe prestar especial atención a los mashups donde la renovación automática está activada.
|
Con estos valores, el número total de solicitudes HTTP por segundo (R) se puede determinar como la suma de llamadas de servicio de mashup (más una para el propio mashup) solicitadas por cada usuario durante ese período de tiempo:
Por ejemplo, hay 3 mashups únicos (M) en la aplicación, con los siguientes parámetros:
• El tiempo de pico de acceso de usuarios es de una hora de duración (t = 3.600 segundos)
• Dos de los mashups realizan 10 llamadas de servicio cada uno (S1 y S2 = 10)
• El tercer mashup efectúa 20 llamadas de servicio (S3 = 20)
• 1.000 usuarios accederán al primer mashup cada hora (U1 = 1000)
• 100 usuarios accederán a los otros dos mashups cada hora (U2 y U3 = 100)
• Ninguno de los mashups se renovará automática o manualmente más allá de esto, lo que describe un escenario en el que los usuarios finales consumen la información proporcionada un vez por cada fragmento en el período de tiempo asignado (de una hora).
(L1, L2 and L3 = 1)
El cálculo sería:
R = [(SM + 1) × UM × LM ] / t
R1 = [(S1 + 1) × U1 × L1] / t
= [(10 + 1) × 1000 × 1] / 3600
≈ 3.06 requests per second
= [(10 + 1) × 1000 × 1] / 3600
≈ 3.06 requests per second
R2 = [(S2 + 1) × U2 × L2] / t
= [(10 + 1) × 100 × 1] / 3600
≈ 0.31 requests per second
= [(10 + 1) × 100 × 1] / 3600
≈ 0.31 requests per second
R3 = [(S3 + 1) × U3 × L3] / t
= [(20 + 1) × 100 × 1] / 3600
≈ 0.61 requests per second
= [(20 + 1) × 100 × 1] / 3600
≈ 0.61 requests per second
R = R1 + R2 + R3
≈ 3.06 + 0.31 + 0.61
≈ 3.98 requests per second
≈ 3.06 + 0.31 + 0.61
≈ 3.98 requests per second
De nuevo, en este escenario, un sistema ThingWorx extra-pequeño con una base de datos simple, como H2, puede gestionar esta carga, pero no se recomienda para el uso en producción.
La mayoría de los cálculos serán más complejos, probablemente con más mashups únicos, cada uno con más llamadas de servicios y usuarios simultáneos de los que se proporcionan aquí.
Aquí se proporcionan dos ejemplos que implican estos cálculos.