¿Cuáles son las estadísticas más importantes que se deben tener en cuenta al implementar una aplicación web Node.js?

monitoring analytics (3)

Cualquiera que sea el tipo de aplicación web, NodeJS o de otro tipo, la prueba de carga responderá si su aplicación tiene la cantidad correcta de recursos del servidor. Un buen sitio web que encontré recientemente para esto es Load Impact .

La verdadera pregunta a responder es ¿CUÁNDO el tiempo de carga comienza a aumentar a medida que aumenta el número de usuarios concurrentes? Se llega a un punto de inflexión cuando se llega a un cierto número de usuarios simultáneos, después de lo cual el rendimiento del servidor comenzará a degradarse. Por lo tanto, realice una prueba de carga según la cantidad de usuarios que espera que alcancen su sitio web en un futuro próximo.

¿Cómo puedes estimar la cantidad de usuarios que esperas?

¡Instalar Google Analytics u otro paquete de análisis en sus páginas es una necesidad ! De esta manera, podrá ver cuántos usuarios diarios visitan su sitio web y cuál es el crecimiento de sus visitas de mes a mes, lo que puede ayudarlo a predecir futuras visitas esperadas y, por lo tanto, la carga esperada en su servidor.

Incluso si conozco la cantidad de usuarios, ¿cómo puedo estimar la carga real?

La respuesta está en las Herramientas de desarrollo F12 disponibles en todos los navegadores. Abra su sitio web en cualquier navegador y presione F12 (o para Opera Ctrl + Shift + I), que debería abrir las herramientas de desarrollo del navegador. En Firefox, asegúrese de tener Firebug instalado, en Chrome e Internet Explorer debería funcionar de inmediato. Vaya a la pestaña Red o Red y luego actualice su página. ¡Esto le mostrará la cantidad de solicitudes HTTP, el uso de ancho de banda por carga de página!

Así que la fórmula para calcular la carga diaria del servidor es simple:

Número de solicitudes HTTP por carga de página X el número promedio de páginas cargadas por usuario por día X Número esperado de usuarios concurrentes = Total de solicitudes HTTP al servidor por día

Y...

Número de MB transferidos por carga de página X el promedio de carga de páginas por usuario por día X Número de usuarios concurrentes esperado = Ancho de banda total requerido por día

Siempre me ha resultado más fácil calcular estas cifras diariamente y luego extrapolarlas a semanas y meses.

Primero, un poco sobre mis antecedentes: he estado programando durante un tiempo (10 años en este momento) y soy bastante competente cuando se trata de codificar ideas. Comencé a trabajar en la programación de aplicaciones web hace poco más de un año, y afortunadamente descubrí nodeJS, lo que hizo que la creación de la aplicación web se pareciera mucho más a la programación tradicional. Ahora, tengo una aplicación node.js que he estado desarrollando durante un tiempo que ahora se está ejecutando en producción en la web. Mi principal confusión proviene del hecho de que soy muy nuevo en el mundo del desarrollo web, y no sé realmente qué es importante y qué no lo es cuando se trata de monitorear mi aplicación.

Estoy usando un Joyent SmartMachine, y ver las opciones de análisis que ofrecen es un poco abrumador. Hay tantas opciones y configuraciones diferentes, y no tengo idea de a qué sirve realmente cada analítica. Para las siguientes preguntas, agradecería cualquier respuesta, ya sea específica de Cloud Analytics de Joyent o completamente general.

PREGUNTA UNO

En este momento, mi principal preocupación es averiguar cómo mi aplicación está utilizando el servidor en el que la tengo funcionando. Quiero saber si mi aplicación tiene la cantidad correcta de recursos asignados a ella. ¿La cantidad de solicitudes que recibe hace que el servidor sea excesivo o justifique recursos adicionales? ¿Qué análisis son importantes para una aplicación NodeJS para ese propósito? (usando tanto MongoDB como Redis en servidores separados si eso hace una diferencia)

PREGUNTA DOS

¿Qué otras estadísticas suelen ser realmente importantes a la hora de gestionar un servidor que está en producción? Estoy acostumbrado a los programas que se ejecutan una vez para hacer algo específico (por ejemplo, un trazador de rayos que termina de ejecutarse una vez que ha computado una imagen), a diferencia de las aplicaciones web que se ejecutan continuamente e interactúan con muchos clientes. Estoy seguro de que hay muchas cosas que son obvias para los administradores de servidores de larga data que no lo son para los novatos como yo.

PREGUNTA TRES

¿Qué es importante tener en cuenta cuando se trata de NodeJS específicamente? ¿Cuáles son las estadísticas / análisis que se vuelven particularmente críticos cuando se trata del bucle de eventos de un solo hilo de NodeJS en comparación con los sistemas de servidor más estándar?

Tengo otras preguntas sobre cómo las bases de datos juegan en la ecuación, pero creo que esto es suficiente por ahora ...

Hemos estado ejecutando node.js en producción casi un año a partir de las series 0.4 y currenty 0.8. La aplicación web es Express 2 y 3 basada en mongo, redis y memcached.

Pocos hechos

el nodo no puede manejar el montón v8 grande, cuando crezca más de 200 mb comenzará a ver un mayor uso de la CPU
Parece que los nodos siempre pierden memoria, o al menos aumentan el tamaño del montón sin utilizarlo. Sospecho que la fragmentación de la memoria, ya que v8 profiling o valgrind no muestra fugas en el espacio js ni el montón residente. A principios de 0.8 fue horrible a este respecto, rss podría ser de 1 GB con un montón de 50 MB.
Es difícil rastrear las solicitudes pendientes. Escribimos nuestro middleware para monitorear esto, especialmente porque nuestra aplicación está basada en encuestas largas

Mis sugerencias.

Utilice varias instancias por máquina, al menos 1 por CPU. Equilibrio con haproxy, nginx o similar con afinidad de sesión
escriba midleware para informar sobre las conexiones bloqueadas, es decir, las que el código nunca respondió o la latencia superó el umbral
reiniciar instancias a menudo, al menos semanalmente
escriba el sondeador que imprime las estadísticas de la memoria con el módulo de proceso uno por minuto
Utilice supervisord y tejido para facilitar la gestión de procesos

Monitorea la CPU, informa las estadísticas de la memoria y reinicia en el umbral

Node.js es de un solo subproceso, por lo que definitivamente debe comenzar un proceso para cada CPU que tenga su máquina. Cluster es, con mucho, la mejor manera de hacer esto y tiene el beneficio adicional de poder reiniciar a los trabajadores muertos y detectar a los trabajadores que no responden.

También desea realizar pruebas de carga hasta que sus solicitudes comiencen a agotarse o excedan lo que considera un tiempo de respuesta razonable. Esto le dará una buena idea del límite superior que puede manejar su servidor. Blitz es una de las muchas opciones para echar un vistazo.

Nunca he usado las estadísticas de Joyent, pero NodeFly y su node-nodefly-gcinfo son una gran herramienta para monitorear procesos de nodo.