Busque respuestas o explore nuestra base de conocimientos.
Diagnóstico de fallas y problemas de escalabilidad en aplicaciones Vantiq
por Paul Butterworth
26 de mayo de 2019
Revisión: 0.30
Introducción
Descubrir y corregir fallas y problemas de rendimiento.
durante el desarrollo de sistemas complejos y de alto rendimiento es siempre una
problema desafiante. Estrategias y técnicas disponibles para investigar y
En este artículo se presentan los problemas correctos.
Este documento fue motivado por cuestiones que surgieron recientemente.
durante el desarrollo de dos sistemas VANTIQ diferentes. Una de las aplicaciones
mostró un error en todo el sistema que parecía irreproducible. El segundo
La aplicación presentaba un persistente problema de escalabilidad. Estas aplicaciones
se utilizarán como ejemplos ilustrativos en este artículo.
Ejemplos de aplicaciones
Solicitud de corredor de eventos
Esta aplicación de Pronto, el corredor de eventos avanzado,
acepta eventos de un sistema ERP como un evento publicado. El evento contiene una solicitud.
para la ejecución de un servicio específico. Hay varios servicios disponibles.
con un evento separado (tema) utilizado para identificar el servicio específico que se está
solicitado. El servicio se invoca enviándole un evento. El servicio responde
con un evento de finalización. La carga útil asociada con el evento de finalización es
posteriormente regresa al sistema ERP invocando una operación REST compatible
por el sistema ERP.
El flujo general de control en la aplicación Pronto es
representado en el siguiente diagrama:
Gestión de ascensores
Esta aplicación, en su primera versión, monitorea hasta
250,000 ascensores. Cada ascensor informa el estado una vez por segundo publicándolo en
un tema utilizando la interfaz VANTIQ REST a través de HTTPS.
La aplicación muestra una tabla que contiene el estado del ascensor.
para un subconjunto seleccionado de ascensores. El usuario puede profundizar para ver el
Estado detallado de un ascensor específico. Una vez seleccionado un ascensor específico,
el usuario ve actualizaciones en tiempo real (una vez por segundo) del estado detallado del
ascensor seleccionado. El usuario puede optar por profundizar y ver el vídeo desde el
ascensor si así lo desea.
La aplicación también calcula una serie de estadísticas a la vez.
intervalo de un minuto. Las estadísticas incluyen el tiempo que el ascensor ha estado en línea,
el recuento y la duración de los movimientos hacia arriba y hacia abajo, la temperatura promedio y
otros. Estas estadísticas por minuto se agregan además para presentarlas por hora,
Estadísticas diarias, semanales, mensuales y anuales de cada ascensor. Agregar
Las estadísticas a efectos de presentación de informes se conservan durante un año.
El estado del ascensor se determina observando
si el ascensor produce informes de estado cada segundo. un ascensor que
no genera informes de estado durante más de un minuto.
desconectado. Si el ascensor publica posteriormente un informe de estado válido, el ascensor
vuelve al estado en línea.
Estrategias de diagnóstico
Existe una amplia variedad de diagnósticos y depuraciones.
estrategias. Este documento es muy obstinado y presenta un conjunto muy específico de
estrategias de diagnóstico que el autor cree que son más efectivas basadas en una
larga trayectoria en el diagnóstico de problemas en sistemas complicados.
Normalmente, los problemas se revelan a nivel del sistema.
problemas:
·
Se están produciendo errores del sistema que indican que la aplicación está
no funciona correctamente.
·
Parte del procesamiento esperado no se produce. El problema puede presentar
síntomas consistentes, el procesamiento esperado nunca ocurre, o puede exhibir lo que
parecen síntomas aleatorios: a veces el procesamiento esperado no ocurre. En
sistemas controlados por eventos, es probable que el problema se informe como "mensajes
perderse".
·
El sistema no escalará para soportar la carga especificada.
·
Las latencias de solicitud son demasiado largas.
La estrategia de diagnóstico general es conceptualmente simple:
·
Construya un modelo simple del sistema.
·
Ejecutar el sistema
·
Inspeccionar los registros de errores
·
Corrija cualquier error del sistema en el registro de errores.
·
Aplicar una carga de trabajo conocida al sistema
·
Corrija cualquier error de agotamiento de recursos
·
Corrija cualquier problema de tiempo de respuesta inaceptable
Los pasos de la estrategia diagnóstica general siempre deben
ejecutarse en este orden. El razonamiento es que no se puede diagnosticar.
Problemas de rendimiento si el sistema no funciona correctamente. Del mismo modo, usted
no puede diagnosticar tiempos de respuesta inaceptables si el sistema ha agotado
recursos disponibles.
La estrategia de diagnóstico depende en gran medida del modo de
sistema como técnica principal de aislamiento de fallas para determinar qué componente del
el sistema es responsable del problema que se está considerando y luego perforando
hasta ese componente, aplicando estas técnicas de diagnóstico de forma recursiva,
hasta que se aísle el problema y se tomen medidas correctivas.
Modelos
La clave para diagnosticar cualquier problema del sistema es tener un sistema simple
modelo de cómo funciona la aplicación en términos de componentes principales y cómo se
fluye de un componente a otro.
Estos no son modelos construidos con el
App Modeler, App Builder o Collaboration Builder. Esos modelos se centran
sobre requisitos y semántica de aplicaciones. No se centran en la escalabilidad ni
¿Identifican claramente los recursos que tienen un impacto importante en el desempeño?
y escalabilidad.
Para el diagnóstico de fallas el modelo debe ser simple. Una regla general
Lo primero es mantener el modelo en alrededor de 6 componentes o menos. Modelos con más
Los componentes rápidamente se vuelven demasiado complicados para razonar fácilmente sobre ellos. Además,
Los componentes más pequeños aumentan la probabilidad de que el problema abarque varios
componentes que complican el problema del aislamiento de fallas.
La descripción de la aplicación Event Broker (arriba)
incluía un modelo informal que describía el flujo básico de la aplicación. Él
También es posible construir un modelo más formal usando un diagrama de secuencia que
muestra el flujo de ejecución de los componentes principales de la aplicación. Si usted
decide formalizar con un diagrama de secuencia, asegúrese de que los únicos recursos
En el diagrama se representan aquellos que tienen un impacto importante en la escalabilidad.
Agregar más detalles sólo servirá para confundir el asunto cuando llegue el momento de
Diagnosticar problemas de escalabilidad. Un diagrama de secuencia de muestra para Event Broker
La aplicación se presenta a continuación:
Para el diagnóstico de escalabilidad, el modelo se organiza en torno a la
casos de uso principales que deben escalar. En este contexto, los modelos deben ser
construido para cada caso de uso de alto tráfico. El modelo para cualquier caso de uso debe
simplificarse hasta el punto de modelar eventos entrantes y salientes y cualquier
actividades de la base de datos realizadas para respaldar el caso de uso. Detalles adicionales son
innecesario en este momento. Si elige diagramar el modelo de escalabilidad, es
Es esencial incluir todas las actividades que consumen recursos en el diagrama:
·
eventos entrantes
·
eventos salientes
·
operaciones de base de datos
·
invocaciones de sistemas externos a través de SOURCE
Ejecución del sistema
Con los modelos en mano es hora de ejercitar el sistema. Si
todavía estás en el proceso de desarrollar el sistema, las pautas para
El ejercicio del sistema está estructurado.
Primero ejecute solicitudes individuales a través del sistema para verificar su
comportamiento. Ejecute solicitudes para cada caso de uso importante que el sistema debería admitir. Si
Si se producen errores, no amplíe las pruebas hasta que se hayan corregido los errores.
Intentar ejecutar una aplicación defectuosa a mayor escala es una completa pérdida de tiempo.
en las transacciones.
Una vez que las ejecuciones de solicitudes únicas sean sólidas y estén libres de errores
Es hora de pasar a cargas de trabajo más complejas. El siguiente paso en el proceso
es aplicar una carga de trabajo que es una secuencia de solicitudes. Esto comprueba que el
El sistema no tiene ningún comportamiento que funcione una vez pero no en las siguientes.
peticiones. Normalmente, estos problemas ocurren porque algún estado almacenado en
la base de datos no se comprende completamente y, por lo tanto, se deja en un estado inconsistente
estado que causa errores en las siguientes solicitudes. Los problemas a este nivel pueden
también ser causado por fuentes en las que el comportamiento del sistema externo no es
bien entendido y las solicitudes de VANTIQ al sistema externo no son
construido adecuadamente para manejar una secuencia de solicitud.
En este punto también podemos echar un primer vistazo a la latencia ya que
podemos recopilar el tiempo que lleva ejecutar la secuencia de solicitudes y determinar
el tiempo medio de respuesta de cada solicitud individual. Los números que obtenemos son
servirá como punto de referencia porque los tiempos de respuesta solo se alargarán a medida que
colocar una mayor carga en el sistema.
Una vez que hayamos completado las ejecuciones simples y corregido
Si se detecta algún fallo, es hora de pasar a cargas de trabajo más grandes y simultáneas. Hacer
No avanzar si el sistema sigue produciendo errores o si el
las latencias ya son inaceptables. Cargas más grandes no aumentarán su
capacidad de diagnosticar los problemas que el sistema ya está presentando. Ver el
sección a continuación: Aplicar una carga de trabajo conocida, para sugerencias sobre cómo cargar
probar la aplicación.
Inspeccionar registros de errores
Una cosa que no podemos enfatizar lo suficiente es que si el sistema
está generando errores, el sistema no está funcionando correctamente e ignorando el
Los errores con la idea de que podrás solucionarlos más tarde nunca funcionan.
Hay momentos en los que se esperan errores pero todos se esperan
Los errores deben ser manejados por la aplicación. Cualquier error que no sea manejado es
Se consideran fallas y deben corregirse.
Corrige los errores
No hay mucho que decir aquí. Los errores deben corregirse
o manejado por el sistema. No hay excepciones. Generalmente los errores producidos
interno al sistema se puede corregir con cambios apropiados en el
código del sistema. Errores producidos como subproducto de la comunicación con externos.
Es posible que el sistema no sea corregible en el sentido de que se puedan eliminar. tales errores
debe ser acomodado por el sistema. Por ejemplo, enviar solicitudes a través de una FUENTE
puede fallar ya que siempre existe la posibilidad de que la red esté caída o el
el sistema externo conectado a la fuente está inactivo o sus credenciales caducan,
etc. En tales casos, el sistema debe poder manejar el problema de alguna manera.
moda elegante. El código para manejar el error debe desarrollarse e incluirse.
además de documentar cualquier procedimiento de recuperación necesario.
Aplicar una carga de trabajo conocida
Empiece a aumentar la carga de forma incremental en este punto. En
En la prueba anterior ejecutamos un flujo secuencial de solicitudes. Sin embargo, queremos
Aplicar la carga de forma controlada para no tener que lidiar con
incógnitas tanto en la carga que se aplica como en el comportamiento del sistema; deseamos
tratar únicamente con incógnitas en el comportamiento del sistema que estamos probando.
La forma más sencilla de proporcionar una carga controlada es utilizar pruebas.
generadores. Sin embargo, los generadores de prueba DEBEN entenderse bien y la carga
que generan deben entenderse bien. Esto es fácil de decir pero difícil de lograr.
El primer error que comete un desarrollador nuevo en temas de escalabilidad es el
construcción de generadores de prueba que no escalan o no aplican los
carga esperada. Por ejemplo, si crea una aplicación que envía 10
solicitudes/seg y realmente necesita una carga de 1,000 solicitudes/seg, es posible que
Imagínese ejecutar 100 copias de la aplicación. Tiene sentido pero luego preguntas.
debe plantearse y responderse:
·
¿Están funcionando las 100 copias del generador en una sola máquina?
·
¿Qué conflictos podríamos ver que causarían que el pan producido
¿Será menos de 1,000 solicitudes/seg?
·
¿No hay suficiente potencia de cálculo?
·
¿No hay memoria suficiente?
·
Problemas de programación que hacen que la carga sea menos uniforme
¿repartido?
·
Problemas de E/S o problemas de red local que podrían limitar la disponibilidad
rendimiento?
Si decide que construir generadores de prueba es demasiado complicado,
Es posible que se sienta atraído por la tecnología de generación de pruebas existente, como Gatling.
(que la ingeniería VANTIQ utiliza para algunas pruebas). Sin embargo, tenga en cuenta que ahora
debe comprender el comportamiento dinámico de Gatling y la infraestructura en
que lo ejecutas. Todas las preguntas anteriores aún deben ser respondidas, pero ahora en el
contexto de la infraestructura de prueba. El beneficio de estas tecnologías es que
Una vez que hayas invertido en comprenderlos, ese agotamiento.
A medida que aumenta la carga de trabajo aplicada, es posible que encuentre recursos
errores de agotamiento. Estos errores son un poco diferentes a los comentados.
anteriormente en que estos no representan errores lógicos en la aplicación.
Más bien representan el hecho de que la aplicación está utilizando más recursos de los que necesita.
ha sido asignado.
Obviamente, hay dos posibles correcciones para esto.
problema:
1. Asignar
más recursos
2. Usa
menos recursos
El enfoque seleccionado es muy importante al considerar el
salud a largo plazo del sistema porque no importa lo que piense, los recursos son
finito. Son finitos porque simplemente no hay más recursos disponibles
o más recursos harán que los costos operativos del sistema superen el presupuesto.
Estas consideraciones afectan si es posible o no aumentar
recursos.
Hacer que el sistema sea más eficiente (es decir, utilizar menos recursos)
Generalmente se requiere si el costo estimado de operación del sistema es superior.
presupuesto o la aplicación choca con un límite estricto en el disponible
recursos.
Los detalles se discutirán en el capítulo: Diagnóstico de escalabilidad
Problemas.
Corregir problemas de latencia
Una vez que el sistema sea capaz de soportar la carga de trabajo
Sin agotar ningún recurso, la siguiente tarea es asegurarse de que las latencias sean
aceptable. Puede que el sistema no esté agotando los recursos, pero sí está utilizando muchos
recursos que las latencias son demasiado largas. Si la aplicación responde en
10 segundos cuando necesita responder en un segundo, hay mucho trabajo por hacer.
Los detalles se discutirán en el capítulo: Diagnóstico
Problemas de escalabilidad.
Resumen
En este capítulo se ha presentado una visión general de la situación general.
Proceso de diagnóstico que recomendamos para errores del sistema y errores de escalabilidad.
Las estrategias de diagnóstico detalladas para errores del sistema se analizan a continuación.
capítulo seguido de un capítulo que analiza estrategias de diagnóstico detalladas para
Problemas de escalabilidad.
Diagnóstico de errores del sistema
Con una aplicación compleja, el primer problema de diagnóstico que
Lo que hay que solucionar son los errores del sistema. Los errores del sistema se encuentran en el registro de errores.
Si encuentra errores en el registro, es probable que su aplicación no funcione
correctamente. Específicamente, si ve errores y esos errores no son
siendo manejado por la aplicación, la aplicación NO funciona correctamente. Él
Es poco probable que pueda explicarlos de manera satisfactoria y lo harán.
¡Continúe plagando todas sus actividades de diagnóstico hasta que las solucione!
Un ejemplo de un error que SE espera y se maneja adecuadamente
se ilustra con la aplicación que utiliza VANTIQ para monitorear la salud de todos
Nubes VANTIQ. La aplicación de monitor espera recibir un evento de cada
Nube VANTIQ cada pocos segundos. Si la aplicación de monitor no recibe una
evento desde una nube en 60 segundos, se produce un error. En concreto, la regla
Se agota el tiempo de espera de un evento. La aplicación de monitor captura el resultado.
excepción y marca el sistema como fuera de línea. Se espera que el error del sistema sea parte
del funcionamiento normal de la aplicación y se maneja adecuadamente dentro
la aplicación.
Otro ejemplo de errores del sistema que se manejan adecuadamente
son solicitudes a servicios REST que pueden expirar porque el servicio REST que se está ejecutando
invocado es lento o poco confiable. La forma correcta de manejar tal falla es:
·
Vuelva a intentar la solicitud porque puede ser un error transitorio.
·
Al volver a intentarlo, es mejor utilizar algún esquema de retroceso exponencial para
reducir el número de reintentos intentados en un servicio REST que va a ser
sin conexión durante un período de tiempo más largo.
·
Si la aplicación necesita una respuesta, convierta el error de un
error del sistema en un error del usuario y proporcionar al usuario instrucciones sobre cómo
proceder.
Si el error no se detecta y la aplicación simplemente
espera que funcione siempre, la aplicación no se ejecutará correctamente.
Este es un buen ejemplo de una
Comportamiento intrínseco exhibido por los sistemas distribuidos. Si una aplicación
se comunica con otra aplicación o servicio a través de una red, hay
Se garantiza que habrá un momento en el que se realizará una solicitud a la aplicación o servicio remoto.
fallará. Esto no es teórico, HABRÁ un fracaso. Para una aplicación
Para ser confiable, cualquier error producido por una solicitud remota DEBE detectarse y
manejado. No intente esquivar este requisito con sutileza. Habrá
eventualmente será un fracaso y debes prepararte para ello.
Veamos un ejemplo de la vida real de cómo diagnosticar una falla en
nuestro ejemplo de Event Broker.
El problema se detectó originalmente cuando se enviaron 100 mensajes.
presentado a la plataforma por el sistema ERP. Desafortunadamente, sólo 90 de los
Los mensajes produjeron resultados exitosos. Este problema se informó como "Pronto es
perder mensajes”. Por supuesto, "Pronto está perdiendo mensajes" informa el externo
comportamiento observado pero no proporciona ninguna idea sobre el problema real que
está provocando que los mensajes se pierdan. Esta clase de informes de problemas, en los que el
Los resultados parecen ser aleatorios, algunos funcionan y otros no.
tradicionalmente una clase de problemas que son muy difíciles de diagnosticar porque
No existe ningún ejemplo de un evento que SIEMPRE vaya a fallar.
Este problema se diagnosticó creando un modelo del sistema.
que constaba de tres componentes de primer nivel:
·
Aceptar solicitudes de SAP
·
Envío de solicitudes a los servicios de destino.
·
Envío de respuestas a SAP.
El enfoque diagnóstico adoptado fue aislar primero el
problema a uno de los componentes principales probando cada componente de forma aislada.
un entorno lo más posible.
1. Prueba
la publicación de mensajes al agente de eventos desde el sistema ERP. Ningún mensaje
se perdieron al ejecutar solo esta parte de la aplicación.
2. Prueba
la entrega de mensajes a los servicios y la publicación de respuestas
al agente del evento. Todos los mensajes fueron entregados y todas las respuestas fueron
publicado.
3. Prueba
la entrega de las respuestas al sistema ERP. No todas las respuestas fueron
entregado ya que se descubrió que algunas solicitudes REST al sistema ERP tardarían
fuera.
En este punto, el problema se limita a un solo componente.
La tarea del desarrollador en este punto es profundizar y determinar las características específicas.
condición que está causando la falla. Hay varios elementos de la
Solicitud que podría ser verificada:
·
¿Es la respuesta demasiado grande y, por lo tanto, el sistema ERP es
¿No puede procesarlo en un tiempo razonable?
·
¿Los tiempos de espera están establecidos en un valor demasiado pequeño?
·
¿Hay algún problema con el servicio VANTIQ REMOTE o su
¿Interacción con el sistema ERP?
·
¿La solicitud REST está formateada incorrectamente? Generalmente esto significa algunos
El encabezado o el tipo de contenido están configurados incorrectamente o no están configurados en absoluto.
Varios de estos problemas potenciales pueden verificarse mediante
construir una interfaz alternativa al sistema ERP. Por ejemplo, utilice CURL para
presentar la misma solicitud con los mismos datos al sistema ERP. si el suplente
La interfaz funciona, la solicitud de servicio REST se puede verificar para asegurarse de que
refleja la solicitud exitosa. Otros problemas pueden comprobarse mediante inspección o mediante
ejecutar una serie de casos de prueba. Por ejemplo, aplicar diferentes tamaños de mensajes
para ver si hay un límite no documentado en el tamaño de un mensaje.
En nuestro ejemplo de sistema ERP, el resultado del análisis detallado
El análisis fue que no había nada malo con las solicitudes en sí mismas o con el
Servicio REMOTO VANTIQ. El sistema ERP simplemente no procesó las solicitudes rápidamente
suficiente o ignorarlos por completo. Fue imposible determinar si el ERP
El sistema fue el problema desde el acceso al sistema ERP para diagnosticar el problema.
no estaba disponible.
El problema se resolvió detectando solicitudes REST fallidas a
el sistema ERP y volver a probarlos. Dado que los fallos fueron aleatorios, se debe volver a intentar
normalmente tendría éxito.
Anteriormente hemos hablado de la necesidad
para inspeccionar los registros de errores y eliminar cualquier error del sistema que no se maneje
por la aplicación. En este ejemplo, el registro contenía errores de tiempo de espera.
informado por la fuente. Una inspección del registro de errores en las primeras etapas del proceso de diagnóstico.
podría haber apuntado directamente al problema y permitido al equipo de desarrollo
aislar más rápidamente el problema. Eso sí, los troncos son, en general, ruidosos.
ya que pueden contener muchas entradas de registro y el significado de los registros individuales
Las entradas pueden perderse en el ruido inherente a un tronco. En tales casos, el
Las técnicas de diagnóstico presentadas anteriormente generalmente resolverán el problema.
La principal lección que relata este capítulo es que en la mayoría de los casos
En algunos casos, el comportamiento incorrecto a nivel del sistema generalmente se puede atribuir a un problema en un
componente específico de la aplicación. Sin embargo, esto no queda claro al visualizar
el comportamiento externo de la aplicación muestra lo que parece aleatorio
fracasos. El truco consiste en dividir la aplicación en unos pocos
componentes y pruebe cada uno de ellos para comprobar si funciona correctamente.
Cuando se agrega un componente a la prueba que presenta un problema, es hora de
Profundice y descubra exactamente cuál es el problema dentro de ese componente y solucione
él.
Diagnóstico de problemas de escalabilidad
Se pueden observar problemas de escalabilidad en cualquier aplicación pero, como
Como regla general, aplicaciones que procesan menos de 100 eventos por segundo.
generalmente no tienen problemas de escalabilidad. Solicitudes procesando más de 100
eventos/segundo o que se espera que crezcan a más de 100 eventos/segundo probablemente
presentan problemas de escalabilidad. El rendimiento y la latencia serán necesariamente claves
preocupaciones.
Los problemas de escalabilidad generalmente se observan cuando el
La aplicación se ejecuta con una mayor carga de trabajo aplicada. La primera indicación
Hay un problema de escalabilidad con la aplicación cuando muestra uno de
los siguientes comportamientos:
·
Los tiempos de respuesta se están alargando sustancialmente
·
Se están superando las cuotas
·
Se están generando errores del sistema (aparte de problemas de cuotas)
·
Se producen fallos aleatorios
En conjunto, los comportamientos observados constituyen el problema.
parece abrumador. Los registros pueden contener miles de errores y tiempos de respuesta.
aumentar rápidamente desde niveles aceptables hasta el punto en que parece que el
La aplicación ni siquiera procesa solicitudes. Sin embargo, algunos sistemas básicos nivelan
Pensar puede ayudarle a manejar el problema.
Construir modelo de rendimiento
Para saber si la aplicación es
realizar correctamente un primer paso esencial es desarrollar un modelo de
aplicación que estima los recursos que utiliza por transacción y
los recursos agregados necesarios para ejecutar la aplicación a escala completa. Edificio
un modelo de este tipo es un ejercicio importante. Si no puedes construir un modelo así, entonces
no sabes cómo funciona tu aplicación y estás condenado a tener
problemas de rendimiento ya que no podrá razonar sobre los recursos
necesario para manejar cualquier evento presentado a la aplicación.
Una forma sencilla de crear un modelo de rendimiento para una aplicación:
·
Identificar los principales casos de uso de la aplicación. Los principales casos de uso son
cualquiera que se ejecute de forma regular. De mayor interés son los casos de uso que se aplican
a cada evento entrante o, al menos, a una gran cantidad de eventos entrantes. Usar
Los casos que sólo se ejecutan ocasionalmente se pueden guardar para un análisis más profundo (si
necesario).
·
Para cada caso de uso
o
Cuente los eventos entrantes.
o
Rastree el flujo de procesamiento para cada caso de uso identificando cualquier
actividades de la base de datos que se ejecutan en nombre del caso de uso. Cuéntalos por
tipo:
§
Seleccionar – una fila
§
Seleccionar – muchas filas
§
recuadro
§
Actualizar
§
al revés
§
Eliminar
o
Rastree el flujo de procesamiento para cada caso de uso identificando
invocaciones de un modelo de aprendizaje automático o llamadas a sistemas externos. Estos son
ambas operaciones costosas que tendrán un impacto significativo en la
escalabilidad de la aplicación.
o
Cuente los eventos salientes
Analizar la carga de trabajo utilizando el modelo de rendimiento
Una vez que se completa el ejercicio de modelado y entendemos el
recursos necesarios para ejecutar cada caso de uso, podemos usar la especificación de carga de trabajo
calcular la frecuencia de cada caso de uso y determinar la carga total que
debe ser manejado por la aplicación. La carga de trabajo generalmente está documentada en
operaciones por segundo (normalmente escritas /segundo). Para escalabilidad
En el análisis nos interesará tanto la carga de trabajo media como la carga máxima.
carga de trabajo. La carga de trabajo máxima es importante porque determina la cantidad de computación
Se debe asignar potencia (recursos) a la aplicación para satisfacer su máximo
demanda de recursos.
Como ejemplo, construyamos un modelo simple del ascensor.
solicitud. Como recordatorio, la aplicación admite un máximo de 250,000
ascensores con cada ascensor informando el estado una vez por segundo. El uso principal
casos son:
1. Cada
Se ingiere y registra el informe de estado de cada ascensor.
2. A
El cliente muestra un resumen del estado del ascensor para un conjunto seleccionado de ascensores como
una lista.
a. Cliente
Puede seleccionar un ascensor y ver el estado detallado en tiempo real de ese ascensor.
3. El
estado en línea/fuera de línea de cada ascensor y el tiempo que ha estado en su
El estado actual se calcula asegurándose de que cada ascensor genere al menos un
evento cada minuto. Cuando se publica el evento único por minuto, se genera un contador.
incrementa y se almacena en la base de datos indicando que el ascensor ha estado en su
estado actual por un minuto más.
4. Ascensor
Las estadísticas se agregan y almacenan una vez por minuto. Los agregados específicos son
tiempo de subida, tiempo de bajada, número de pisos visitados, temperatura media.
5. Clientes
Puede mostrar estadísticas de un ascensor por hora, día, mes y año.
base.
El modelo de rendimiento correspondiente para el ascensor:
Eventos entrantes: 250,000/seg.
Caso de uso 1: almacenar el entrante
informe de estado insertándolo en la base de datos. Esto nos da 250,000
upserts/seg en todos los ascensores.
Caso de uso 2: asumir la visualización de estado
Se actualiza una vez cada 10 segundos para cada cliente. 100 ascensores se muestran por
cada cliente. Hay 200 clientes. Suponiendo una distribución uniforme, esto da
us 20 selecciones/segundo y cada selección devuelve 100 ascensores (objetos).
Caso de uso 3: utilizar una actividad faltante
patrón para detectar ascensores que no han enviado un informe de estado en más de un
minuto. Registre el hecho de que este ascensor está fuera de línea en la base de datos. Usa un límite
patrón de actividad para determinar los ascensores que están en línea. En el minuto
Incrementar el tiempo en línea para el ascensor realizando una actualización en el tipo.
que contiene el estado actual del ascensor. Esto resulta en 4,167
actualizaciones/seg. También debemos observar que una simple lectura de las estadísticas da
nosotros 4,167 operaciones de base de datos/seg pero, en realidad, el límite de actividad va
para programar este procesamiento para todos los ascensores en línea en el momento del minuto
se alcanza el intervalo. Por lo tanto, a plena carga, esto pondrá en cola tantos como sea posible.
250,000 actividades instantáneamente, cada una de las cuales eventualmente generará un
solicitud de base de datos.
Caso de uso 4: agregar datos entrantes
cada segundo utilizando estadísticas en tiempo real de VANTIQ. Además, utilice un límite
patrón de actividad para activar un evento por minuto para cada ascensor. Cuando el
El límite desencadena un evento, escriba las estadísticas del último minuto en un registro. Asumiendo
una distribución uniforme, esto da como resultado 4,167 upserts/seg. También necesitamos
observe que una simple lectura de las estadísticas nos da 4,167 bases de datos
operaciones/seg pero, en realidad, la actividad límite va a programar esto
procesamiento para todos los ascensores en línea en el momento en que se alcanza el intervalo de minutos.
Por lo tanto, a plena carga, esto pondrá en cola hasta 250,000 actividades.
instantáneamente, cada uno de los cuales eventualmente realizará una solicitud de base de datos.
Caso de uso 5: estos son agregados
consultas durante la última hora, día, semana, mes, año por minuto
Estadísticas. Supongamos que la consulta promedio es para un mes de datos que asciende
a 60 * 24 * 30.5 registros que deben agregarse. Esto equivale a: 43,920
registros por consulta promedio. Supongamos además que, en promedio, sólo uno de esos
el agregado se ejecuta simultáneamente.
Los titulares de esta aplicación:
·
Eventos: 250,000/segundo
·
Upserts: 258,334/segundo
·
Consultas: 11/segundo.
Con estos datos en la mano podemos estimar los recursos informáticos.
necesarios para soportar esta carga de trabajo.
·
250,000 eventos/segundo. Supongamos que una sola vCPU puede procesar 1,000
eventos/seg, lo que implica 250 vCPU. Suponiendo máquinas de 4 núcleos, eso nos da 63 4vCPU
máquinas para procesar los eventos.
·
258,334 upserts/segundo no es viable porque asumimos el DBMS
No puede realizar más de 20,000 upserts/segundo. Este es un límite estricto, así que esto
indica que la aplicación NO SOPORTARÁ SU CARGA DE TRABAJO MÁXIMA. No hay negociación
posible. La aplicación deberá utilizar una arquitectura diferente.
·
11 consultas por segundo es poco en comparación con el resto de la carga de trabajo;
por lo tanto, lo ignoraremos.
·
El patrón de actividad límite que se activa una vez por minuto no
En realidad, no distribuye los eventos que produce de manera uniforme a lo largo del minuto.
intervalo. Más bien, cuando suena el cronómetro de minutos, todo el trabajo del último
minuto está programado. Esto significa que se publican hasta 500,000 eventos casi
simultáneamente. Dado que el sistema no podrá procesar los eventos.
Al instante, el trabajo quedará en cola. Desafortunadamente, el sistema no hará cola.
tanto trabajo sin comprometer gravemente la memoria. Para evitar el
problemas de memoria, las colas son de tamaño limitado y el intento de ponerlas en cola
mucho trabajo resultará en un gran número de violaciones de cuotas. Este es otro
problema de escalabilidad para esta aplicación que debe abordarse.
Este ejercicio ha demostrado uno de los beneficios de la
modelo. Tomó menos de una hora definir los casos de uso y construir el modelo.
Proporciona una descripción bastante precisa del procesamiento de la solicitud y
dejó en claro que la aplicación tal como se imagina simplemente no admitirá lo especificado
carga de trabajo. No es necesario escribir ningún código; no es necesario ejecutar ninguna prueba de estrés. En cambio,
en una hora descubrimos que DEBEMOS desarrollar una arquitectura más escalable.
Desarrollo de una arquitectura de aplicaciones escalable
Ahora que hemos demostrado nuestra aplicación inicial.
La arquitectura no es escalable, debemos desarrollar una arquitectura más escalable que
aborda los problemas identificados analizando la carga de trabajo aplicada al modelo.
Primero abordamos una de las partes más problemáticas del
Carga de trabajo: las 250,000 upserts/segundo necesarias para capturar el estado en tiempo real.
de todos los ascensores. Además, el estado se captura con el único propósito
de mostrarlo a un máximo de 200 clientes. ¿Podemos encontrar una arquitectura que
es más eficiente para llenar las pantallas del cliente que almacenar cada estado
informe en la base de datos?
Hay algunos enfoques alternativos discutidos en el
subsecciones siguientes.
Transmita el estado directamente a los clientes
Un enfoque es transmitir el estado directamente desde el
evento entrante al cliente. La versión más agresiva de tal
La arquitectura no realiza operaciones de base de datos de ningún tipo. Observe que hay un
máximo de 200 clientes y cada cliente puede mostrar el estado en tiempo real de
exactamente un ascensor en cualquier momento. Además, la selección de ascensores para cualquier
El cliente no cambia muy rápido. En promedio, llamémoslo una vez cada 30.
minutos. Eso significa que estamos cambiando, en promedio, una pantalla de ascensor.
asignación cada 9 segundos.
En tiempo de ejecución, el sistema tiene que enviar el estado a cualquier cliente.
es decir, se muestra el ascensor para el cual se está procesando un informe de estado.
Una forma de hacer esto es hacer que cada cliente escuche un tema único sobre el cual el
El estado en tiempo real del ascensor que el cliente está mostrando actualmente es
publicado. Para vincular este tema de cliente a los eventos de estado para el designado
ascensor, construimos dinámicamente una regla que detecta un informe de estado para un
ascensor particular y vuelve a publicar el evento en el tema exclusivo del cliente. Nota
que estas reglas deben construirse sobre la marcha a medida que cada cliente selecciona un
ascensor para ver pero, a las tarifas de las que estamos hablando, creando dinámicamente
estas reglas no deberían ser una carga tan grande.
Una alternativa a la creación dinámica de reglas para vincular clientes
a los ascensores es volver a publicar cada evento de estado del ascensor que llega en un formato único.
Tema para cada ascensor. Por supuesto, esto implica que tenemos 250,000 temas, pero
una gran cantidad de temas no son un problema de escalabilidad. Cuando un cliente selecciona un
Ascensor para mostrar el estado en tiempo real, el cliente se suscribe al tema.
correspondiente a ese ascensor para recibir el estado en tiempo real.
Utilice SELECTS para reducir el número de UPSERTS
Otra alternativa es convertir los upserts en selecciones.
En este caso cada cliente registra su interés en un ascensor añadiendo un
objeto a un tipo. Cuando llega un informe de estado, la regla que procesa el estado
informes consulta la base de datos haciendo una selección y envía el informe de estado a
cualquier cliente que esté observando ese ascensor. Esto convierte los 250,00
actualizaciones/segundo a 250,000 selecciones/segundo (para comprobar si hay clientes observadores).
Dado que las selecciones son probablemente 10 veces más eficientes que las inserciones, es mucho más
Es probable que el sistema pueda soportar la carga seleccionada de manera más eficiente que la carga upsert.
carga. Sin embargo, parece que este enfoque sigue dedicando demasiadas
recursos para hacer que el estado esté disponible para mostrarlo a nuestros 200 clientes.
Una variante de la arquitectura anterior que continúa almacenando
el estado en la base de datos dependerá de las propiedades estadísticas de la
informes de estado del ascensor para reducir la carga de trabajo al convertir los upserts en
selecciona y seguido de menos inserciones. La propiedad estadística de este enfoque.
Lo que depende es que los ascensores informan el estado con frecuencia, pero el estado real del ascensor
no cambia eso, lo que a menudo hace que muchos de los informes de estado sean redundantes.
Los ascensores están inactivos un gran porcentaje del tiempo, por lo que su estado real es
no cambiando. Explotando esta semántica, el sistema recupera el estado actual.
de cada ascensor cuando llega un informe de estado. Si el estatus actual y el
Los nuevos estados son semánticamente idénticos, no se moleste en realizar la actualización. Solo una suposición
En este punto, pero sospecho que es probable que la cantidad de actualizaciones se acerque más a
5,000/segundo que 250,000/segundo usando este enfoque. Sin embargo, todavía tenemos que
lidiar con 250,000 selecciones/segundo. Esto es más fácil de gestionar que el mismo número.
de upserts, pero sigue siendo un gran número de operaciones que implican la
El costo operativo de la aplicación será mayor de lo que preferiríamos.
Estado UPSERT solo para ascensores que muestra un cliente
A continuación, analizamos un esquema que reduce la tasa de upsert en
almacenar informes de estado sólo para los ascensores que se están viendo. Esto es
Esto se logra mediante la construcción dinámica de una regla cuando un cliente se suscribe a
Actualización de estado de un ascensor. La regla detecta si una actualización de estado es para el
ascensor que se muestra. Si es así, escribe el estado en la base de datos. De este modo,
el único estado realmente escrito en la base de datos es para aquellos ascensores que
están vinculados a visualizaciones en tiempo real. Cuando el cliente cambia a otro ascensor,
se elimina la regla.
Reducir la tasa de muestreo
Un último enfoque es simplemente reducir la tasa a la que
Se registran las actualizaciones. Por ejemplo, si elegimos almacenar solo uno de cada diez estados
informe, la tasa de upsert se reduce en un orden de magnitud a aproximadamente 25,000
upserts/segundo: una tasa que aún es muy alta pero que puede ser posible.
Desafortunadamente, esto puede ser práctico pero no es muy satisfactorio porque estábamos
requerido para cambiar los requisitos de la aplicación y solo puede mostrar
El estado se recopila cada diez segundos. La visualización en tiempo real del cliente es menor.
en tiempo real que el especificado originalmente.
Diagnosticar problemas de escalabilidad en aplicaciones en desarrollo
La sección anterior ilustra
Cómo construir un modelo es un enfoque muy eficiente para evaluar la aplicación.
arquitecturas desde el punto de vista del rendimiento. Sin embargo, esto no siempre es
posibles aplicaciones existentes que presentan problemas de escalabilidad. En esto
En esta sección analizamos estrategias para diagnosticar problemas en aplicaciones que son
en desarrollo o se puede poner en desarrollo para diagnosticar
Problemas de escalabilidad. Aplicaciones de producción que no se pueden cambiar ni colocar en
El desarrollo se analiza en otro documento (aún por escribir).
Como se analizó anteriormente, una aplicación VANTIQ existente con
Los problemas de escalabilidad exhibirán uno de los siguientes comportamientos:
·
Errores
·
Disminución de los tiempos de respuesta (o ninguna respuesta)
Errores
Lo primero que hay que inspeccionar son los registros de errores. Tratando de
Averiguar qué está haciendo su aplicación o cómo se está desempeñando es una pérdida de tiempo.
tiempo si produce errores constantemente. Los errores enmascararán cualquier utilidad
información sobre el comportamiento dinámico de la aplicación.
Hay dos clases de errores a considerar:
·
Errores de usuario
·
Errores de aplicación
Se esperan errores de usuario y normalmente no son un problema.
Son generados por usuarios que cometen errores en la entrada o configuración de datos.
actividades. Por ejemplo, el sistema le pide al usuario un archivo y el usuario escribe
en un nombre de archivo. Algún porcentaje razonable del tiempo que el nombre del archivo será
escrito incorrectamente y se generará un error de "archivo no encontrado". Típicamente,
Dichos errores no son motivo de preocupación, ya que son esperados y manejados por el
.
Por el contrario, los errores del sistema son inesperados y sus
ocurrencia interfiere con el comportamiento adecuado de la aplicación. Algunos típicos
los errores incluyen:
·
Tiempos de espera. Cualquier cosa que se agote probablemente sea un problema.
Los tiempos de espera ocurren por dos razones:
o
Algo no funciona. Esto normalmente se aplica a las operaciones IO.
Un ejemplo clásico es invocar un servicio REST y la solicitud caduca antes
se completa. Esto puede ser un problema de red, un problema en el servicio remoto.
o es posible que le haya pedido que haga demasiado trabajo y no pueda responder a tiempo.
Estos problemas también pueden deberse a redes deficientes o sobrecargadas. Lo peor
El caso es cuando estos errores no son muy predecibles y el desarrollador tendrá que
profundizar más para encontrar la raíz del problema.
o
Se está haciendo demasiado trabajo. VANTIQ tiene un límite máximo
tiempo de ejecución de un procedimiento. Ese límite es de 2 minutos. Si le pide al sistema que haga
algo que demore más de dos minutos recibirá un error. Lo correcto
La respuesta a tal error es dividir el trabajo para que pueda realizarse en grupos más pequeños.
trozos
·
Errores generales de ejecución. Puede haber muchas razones para una amplia
rango de errores de tiempo de ejecución:
o
Recurso faltante: llamar a un procedimiento que no existe.
Llamar a un procedimiento remoto que no existe. Hacer referencia a un tipo que no
no existe. En VANTIQ este puede ser un recurso remoto que no existe, así que paga
atención a los mensajes de error.
o
Fallos en el código VAIL. Pueden ocurrir todos los errores habituales, como
variables faltantes, asignaciones no válidas, etc.
o
Eventos faltantes. Estos son insidiosos porque la aplicación puede generar un
evento que nadie está escuchando. Por el contrario, tu aplicación puede estar escuchando, pero
nadie esta publicando. Muchas veces estas inconsistencias son causadas por errores tipográficos en
los nombres de los temas. Pronto puede ayudar a diagnosticar estos problemas porque ambos
Los editores y suscriptores aparecen en el catálogo, por lo que es fácil ver si
te falta la mitad de la ecuación.
·
No manejar los valores de retorno correctamente. Esto es insidioso
problema ya que se devuelven valores pero no son los valores esperados.
Es fundamental leer y comprender la documentación sobre cómo los valores de retorno
se producen porque nuestro modelo de ejecución asincrónica no siempre coincide
su intuición sobre cómo se produce el valor de retorno.
·
No manejar los resultados de las consultas en forma de transmisión. si lo logras
una matriz, seguramente tendrá problemas en consultas generales.
·
Errores de autorización cuando el usuario no tiene suficientes derechos para
acceder a algo.
·
Errores de configuración particularmente al hablar con sistemas externos.
·
Agotamiento de recursos y violaciones de cuotas para los recursos asignados
a la aplicación. Esto significa que tiene una aplicación defectuosa que
consume todos los recursos disponibles o la aplicación está haciendo más trabajo que el
los recursos que se le asignan lo permiten. Los errores de cuotas y recursos son una discusión clave
tema a continuación.
Errores de cuotas y consumo de recursos
Cualquier error que represente una violación de cuota y recursos.
DEBE corregirse. A una organización se le asigna una cantidad específica de
recursos y no pueden exceder esos límites. Los límites se establecen mediante cuotas.
Los límites incluyen la cantidad de reglas que pueden estar activas en cualquier momento,
el número de reglas en cola esperando ejecución, el tiempo de ejecución de los procedimientos
(que siempre se establece en un máximo de 2 minutos) y la velocidad máxima a la que
Los eventos se pueden presentar al sistema. El resultado de un mensaje de cuota excedida
es que algunas partes de su aplicación están siendo canceladas. Por lo tanto, la
¡La aplicación no puede ejecutarse correctamente!
Evalúe si la infracción se debe a que su aplicación no está disponible
controla y utiliza demasiados recursos o sus cuotas son demasiado bajas. Este tipo de
El análisis generalmente requiere algún tipo de análisis del uso de recursos de su
aplicación proyectada sobre la carga que está aplicando actualmente como anteriormente
discutido en la sección de modelado.
Si determina que su aplicación está utilizando recursos como
esperado y está utilizando recursos dentro del presupuesto especificado. El alivio de la restricción puede
lograrse solicitando cuotas mayores. Una solicitud que indica cuáles son las cuotas
debería ser siempre el más sencillo de tratar. Una petición sin cuantitativa
Las demandas probablemente resultarán en un proceso iterativo en el que las cuotas se
aumenta, la aplicación se vuelve a probar y se solucionan las infracciones de cuota restantes
aumentando nuevamente las cuotas.
Aumentar las cuotas sólo funciona si
hay más recursos disponibles. En el ejemplo del ascensor donde 250,000
La arquitectura inicial de la aplicación requería actualizaciones/seg. No hay
cuota que se puede asignar que hará que la aplicación funcione. La aplicación
simplemente exige más recursos de los que se pueden proporcionar. El aumento de las cuotas
no resolver este problema.
Si el problema es que no se dispone de recursos informáticos adecuados
disponibles, se deben proporcionar recursos informáticos adicionales. En términos simplificados
Esto implica aumentar la potencia de cálculo del clúster de servidores VANTIQ en
agregar máquinas adicionales o aumentar el tamaño de las máquinas existentes.
Si el problema es que no se dispone de los recursos adecuados de la base de datos
disponible, es posible aumentar el tamaño de los servidores que ejecutan el
SGBD. Sin embargo, no puede aumentar la capacidad agregando servidores DBMS adicionales.
Por lo tanto, existe un límite superior en la cantidad de recursos de base de datos que pueden
ser suministrado.
Un par de casos insidiosos incluyen aplicaciones que ponen en cola
grandes cantidades de trabajo en un corto período de tiempo. El patrón de actividad LIMIT es
un buen ejemplo donde puede poner en cola una gran cantidad de trabajo cuando el límite
expira el intervalo. Si se presenta demasiado trabajo a la vez, se realizará un diagnóstico de cuota.
indicar que ha excedido su cuota y ha puesto en cola demasiados eventos. Cuotas
se puede aumentar hasta cierto punto pero, en muchos casos, es necesario volver a trabajar la aplicación
Se requiere una arquitectura para facilitar la entrega de solicitudes al sistema.
Un fenómeno relacionado es el elevado nivel de transacciones
Las aplicaciones de velocidad solo funcionan bien si la carga permanece bastante constante. Si usted
están ejecutando 100,000 eventos/seg y aumentan periódicamente la carga a 200,000
eventos/seg, es posible que el sistema nunca se estabilice completamente después de que se haya aplicado la carga máxima.
presentado. Esto conduce a mayores latencias y un uso excesivo de recursos. Para
Las aplicaciones con altas tasas de transacción intentan mantener la carga lo más estable posible.
Latencias excesivamente largas
Cuando un sistema está sobrecargado, los tiempos de respuesta se degradan en un
moda exponencial. Los sistemas verdaderamente sobrecargados generalmente parecen estar colgados.
Por supuesto, en algunos casos, si esperas lo suficiente, obtendrás una respuesta, pero
Esta es una victoria pírrica ya que cualquier usuario normal consideraría que el sistema está colgado y
no responde.
La respuesta habitual a latencias largas es instrumentar el
aplicación en detalle, ejecute la aplicación grabando toda la instrumentación y luego
Inspeccione los resultados registrados para intentar identificar dónde está ocurriendo el problema.
Este enfoque generalmente confirma que hay un problema, pero rara vez soluciona el problema.
Ubicación del problema obvia. El ejemplo más extremo de exceso
La salida del diagnóstico es la creación de perfiles de ejecución. El perfilado proporciona muchos detalles
pero, si busca un problema del sistema, probablemente sea demasiado detallado. A
Un mejor enfoque es volver al modelo simplificado de la aplicación y
instrumentar cada uno de los componentes principales con instrumentación de tiempo transcurrido. Entonces
ejecute la aplicación e identifique qué componente está produciendo el exceso
tiempo de ejecución y, por implicación, las largas latencias. Una vez que un componente ha sido
identificado, utilice un enfoque de descomposición para instrumentar aún más la aplicación
hasta que haya identificado un problema específico que pueda ser atacado.
Lo más probable es que el problema sea un uso excesivo de recursos en
la aplicación VANTIQ o sobrecargar un sistema externo que ha sido
Integrado con la aplicación VANTIQ. Las integraciones externas son un área clave para
centrarse en cuando se producen latencias excesivamente largas.
Grafana
VANTIQ proporciona instrumentación para la observación de recursos.
consumo dentro de los sistemas VANTIQ. Esta información está disponible en Grafana.
paneles de control disponibles en VANTIQ IDE.
Una de las ventajas de los paneles de Grafana es que
se puede utilizar para confirmar la precisión de su modelo de aplicación. Hay
Varios paneles de control disponibles:
·
Ejecución de reglas
·
Ejecución del procedimiento
·
El uso de recursos
·
Actividad de origen
·
Tipo de almacenamiento
Para los sistemas controlados por eventos, el primer panel a observar es
el panel de ejecución de reglas. La ejecución de la regla muestra la regla agregada
tasas de ejecución, así como tasas de ejecución para cada regla específica. Si usted tiene
ha desarrollado un modelo preciso de la aplicación y está aplicando una carga conocida,
Las tasas de ejecución para cada regla y el sistema en su conjunto deben coincidir con sus
modelo. Si las tasas no coinciden, tiene trabajo que hacer para desarrollar una información más precisa.
¡modelo!
Primero verifique que se estén ejecutando todas las reglas. Específicamente,
verificar que el caído y fracasado las tarifas son cero. Si estas tarifas
no son cero, las reglas no se están ejecutando hasta el final. Esto puede ser causado por:
·
errores (ejecuciones fallidas de reglas)
·
su aplicación excede su cuota (eliminada)
·
Otra aplicación que se ejecuta con la misma organización es
superando su cuota
Como se indicó anteriormente en este
documento, no tiene sentido intentar escalar la aplicación si falla.
¡Ocúpate de estos errores ahora!
A continuación se muestra una captura de pantalla del panel
mostrando un intervalo de ejecución en el que se excedieron al menos dos cuotas
errores a las 13:39 y 13:40.
Los errores apenas son visibles.
ya que Word ha reducido la resolución de la captura de pantalla. Ampliando el
área relevante en la imagen de la pantalla de arriba, puede ver dos pequeñas marcas azules justo
antes y a las 13:40 en la imagen de abajo. Las marcas azules representan una cuota superada
fallos de ejecución.
El error también se ha registrado
en el registro de errores y se duplica a continuación:
Error en un recurso de
escriba 'auditorías' con id '/rules/catchTimer' Alerta de auditoría: el
El crédito de ejecución para la organización Vantiq se ha consumido. Como resultado el
La regla catchTimer está siendo limitada.
|
|
|||||||||||||||||
|
|
||||||||||||||||
En este punto sería fácil
Intente ignorar este error. Nuestra aplicación solo ejecuta dos eventos por segundo y
no puede exceder su cuota. Hacer tal suposición simplemente le hará perder el tiempo.
Hay que diagnosticar el problema. En este punto revisamos el código y aseguramos
Nosotros mismos esperamos ejecutar dos reglas/seg. Luego revisamos el
panel de control a más largo plazo y confirmó dos reglas/segundo es nuestra ejecución
tasa. Finalmente, observamos que estamos corriendo en una organización que contiene
una serie de aplicaciones adicionales y es una de esas aplicaciones que es
exceder la cuota de la organización. Desafortunadamente, las consecuencias de esto son que
nuestra aplicación queda atrapada en el fallo. Esta es una lección MUY IMPORTANTE para
aprender. Si está intentando medir la escalabilidad y el uso de recursos con precisión
debe estar ejecutando en un entorno aislado donde otros usuarios no estén
competir con usted por una parte de las cuotas de recursos.
Esta es una razón clave por la que VANTIQ
recomienda que los equipos SE y PS observen las siguientes reglas al construir
aplicaciones:
·
Demostraciones: las demostraciones no se ejecutan a escala y se pueden ejecutar en VANTIQ
organizaciones como:
o
VantiqEval
o
VantiqPOC
·
PoC: no se ejecutan a escala; se utilizan para demostrar
capacidades (no escala) a prospectos de alto valor. Las PoC se pueden ejecutar en VANTIQ
organizaciones como:
o
VantiqEval
o
VantiqPOC
·
Pilotos: los pilotos son aplicaciones que se construyen para
prospectos/clientes y generalmente son patrocinados y pagados por el cliente.
Los pilotos generalmente tienen que demostrar la escalabilidad y, por lo tanto, deben ser
desarrollado en una organización separada dedicada al proyecto piloto. En algún
punto, el piloto puede ser entregado al cliente y este se convierte en el
organización de desarrollo del cliente.
·
Aplicaciones: las aplicaciones solo están diseñadas para clientes y son de pago.
por parte de los clientes. Las aplicaciones deben desarrollarse y probarse en una organización.
dedicado al cliente.
Si ignora estas reglas e intenta escalar aplicaciones en
el espacio de nombres VANTIQ no sólo fracasará sino que dañará el desarrollo
esfuerzos de sus colegas.
El panel de ejecución de reglas también indica los tiempos de ejecución.
por las reglas. La pantalla incluye p50 (el tiempo medio de ejecución) y p99
(el 99th percentil que normalmente interpretamos como el peor de los casos
tiempo de respuesta). Estos valores son importantes si son mayores de lo esperado.
o más grande de lo que puedes tolerar. Por ejemplo, el siguiente ejemplo del panel muestra
ejecución de reglas por debajo de 20 ms en el nivel p50 y 250-300 ms en el nivel p99
nivel. El número p99 siempre será más volátil ya que representa
peor comportamiento de los casos y se ve afectado por cualquier retraso en el procesamiento de la
regla. Por ejemplo, una recolección de basura podría tener un impacto importante. Para el ejemplo
aplicación, esto no es un problema ya que recibimos un evento/segundo y,
por lo tanto, tenga 1000 ms para ejecutar cada regla antes del siguiente evento
llega. Sin embargo, si los tiempos de ejecución están siempre por encima de 1000 mseg tenemos el
problema de que la ejecución de la regla no se completa antes de que llegue el siguiente evento. Este
es una condición crónica, entonces el trabajo nuevo llega más rápido de lo que se completa,
y el sistema pondrá en cola cada vez más trabajos hasta colapsar.
La imagen de arriba muestra un panel de ejecución de reglas de Grafana para
una aplicación que ejecuta 2 reglas/seg. en estado estacionario y sin
errores.
Otro panel que es bastante valioso es el Recursos
Panel de uso. Este panel muestra seleccionar, insertar, actualizar y eliminar actividad.
sobre los recursos (tipos) almacenados en el almacenamiento persistente.
Advertencia: puedes dejarte llevar fácilmente
extraviarse por esta pantalla si no presta atención a la configuración "api" como
El panel muestra el uso de recursos desde la interfaz REST o desde VAIL.
aplicaciones. Es fácil pensar que está observando la actividad de reglas (VAIL) cuando
en realidad estás mostrando actividad originada en la API REST (o viceversa).
viceversa)
Como se observó anteriormente en este documento, los recursos de la base de datos
representan el límite máximo de escalabilidad dentro de VANTIQ. Otros recursos pueden
ser incrementado. Si su aplicación necesita ejecutar un millón de reglas por segundo más
La potencia de cálculo resolverá el problema. Sin embargo, la base de datos tiene un límite superior.
en escalabilidad. Esto significa que las cifras de uso de recursos son muy importantes y,
en particular, que el rendimiento agregado de los recursos se mantenga dentro de un rango razonable
rango.
Nuestra regla general es permanecer soltero
actividad SELECT de objeto por debajo de 20,000 XNUMX solicitudes/s y actualizaciones de un solo objeto
por debajo de 5,000/seg.
También es importante prestar atención a la operación.
tiempos de respuesta ya que los tiempos de respuesta excesivos tendrán un efecto similar aquí como
lo hace en la ejecución de reglas donde el trabajo comienza a llegar más rápido de lo que puede ser
procesado.
La imagen de arriba muestra un panel de uso de recursos para el
La misma aplicación ejecuta 2 reglas/seg. Cada regla realiza una actualización a una única
objeto en un solo tipo. Por lo tanto, el sistema está realizando 2 actualizaciones/seg.
estado estable.
Resumen
Hemos discutido una serie de enfoques para diagnosticar
fallas y problemas de escalabilidad en los sistemas VANTIQ. La discusión no es
exhaustivo presentando sólo una muestra representativa de las técnicas disponibles
para diagnosticar y corregir los problemas descubiertos.
Esperamos que encuentres esta información útil.
Si tienes otras técnicas que hayas utilizado para atacar estos
problemas, documentelos y los agregaremos a esta guía.