¿Qué parámetros del servidor se utilizan para rastrear el rendimiento del servidor y decidir sobre la escala hacia arriba / abajo? ¿Y en qué valores?

Los valores dependen del usuario y de la aplicación. ¿Tiene un requisito comercial para cierto rendimiento en todo momento o en ciertos momentos? ¿Puedes vivir con un tiempo de respuesta degradado? ¿Cuáles son sus umbrales de costo? ¿Es su aplicación generalmente muy variable en la forma en que consume recursos? ¿Requiere que las instancias se aceleren cuando esto sucede, o cuando ocurre varias veces, lo que indica un aumento de los requisitos generales de recursos?

Puedes rastrear:
– Uso de CPU (aumento en ALTO%, apagado en BAJO%)
– Uso de RAM (igual que el anterior)
– Eventos (de su lista: ¿cuánto tiempo se tarda en borrar, hay una acumulación de trabajo atrasado?)
– Tráfico de red (puede saber que el tráfico de red hace que su aplicación funcione de una manera determinada que tiene un efecto multiplicador a lo largo de su implementación en los recursos necesarios)
– E / S de disco (hay un límite de E / S que lo ralentizará: ¿cuál es su umbral de rendimiento?)

Cuando realiza un seguimiento de estas cosas, puede configurar la ampliación hacia arriba y hacia abajo en función de:

– Período de tiempo: IE: CPU superior al 80% promedio en instancia / clúster durante 10 minutos = agregar x recursos. (converse = eliminar si está por debajo de x% para un período de tiempo)

– Hora: hora del día / semana / año: si se produce un pico o caída durante un período de actividad intensa, por ejemplo, en Navidad para un negocio estacional, es probable que desee agregar recursos; Si ocurre un pico en la noche, tal vez no le importe, o solo tenga un umbral de cuántos recursos agregar.

– Actividad: Basándose simplemente en el uso que está rastreando, configure la escala en línea con su aplicación para que siga funcionando de manera eficiente. Usted decide cuáles son los umbrales de uso superior e inferior.

– Presupuesto: a pesar de los requisitos técnicos, siempre hay un presupuesto para trabajar. No desea usar esto en un día escalando recursos ilimitados para mantener la aplicación en funcionamiento; debe tener tolerancias. Un máximo diario o semanal, con alertas para que pueda decidir aumentarlo temporalmente para mantener las cosas en funcionamiento. Debido a que la nube es un recurso variable (a diferencia de la TI tradicional cuando compra una cantidad fija de hardware), los costos son variables, lo que significa que pueden escalar muy fácilmente.

Después de probar una serie de variables diferentes, hemos pasado a usar una carga de cinco minutos (usamos Linux; no estoy seguro si hay un equivalente obvio de Windows), porque en las pruebas de carga, nuestros servidores de aplicaciones web sobrecargan la CPU antes que la memoria (o cualquier otra cosa) . Esto se debe a que hemos creado nuestra aplicación web con nginx y uWSGI para hacer que las solicitudes adicionales esperen, teniendo un número fijo de subprocesos de ejecución.

Intentamos cosas como mirar todos los núcleos individualmente o varias medidas de E / S, pero la carga de cinco minutos fue más confiable. Actualmente tenemos nuestro umbral establecido en el 50% del número de núcleos (por lo que en un c1.xlarge en Amazon, que tiene 8 núcleos, nuestro límite de carga de cinco minutos es 4, y luego lanzaremos otro par de servidores [nosotros use Amazon ELB, así que lanzamos en pares]).