Hago mucho rendimiento y trabajo de escala y lo que he descubierto es que:
Cada carga de aplicación es única
Las respuestas genéricas, como agregar más ram, obtener otro servidor, hacer y, probar x, a menudo son lecciones de frustración y se dejan en configuraciones complicadas.
Medir las cosas correctas
Uno de los mayores desafíos es determinar qué puntos de referencia son importantes. Esto a menudo requiere un paso atrás y tienes que ponerte en el lugar de tu cliente. A veces, el diseño simplificado del sitio cambia y significa enormes beneficios para el visitante web. ¡Por eso me gustan las herramientas como YSlow! que se centran más en la experiencia del usuario final que en el nivel del servidor. Una vez que decida cuál es el punto de referencia correcto para su sitio, puede comenzar a ajustar. Los puntos de referencia pueden ser el tiempo total de carga de la página, el tamaño total de la página, la efectividad de la memoria caché, la latencia del sitio, etc. Debe elegir el que tenga sentido para su aplicación.
Tuercas y tornillos
Una vez que esté siguiendo los puntos de referencia correctos, comience en un nivel muy bajo. Me gusta usar sysstat. Puede obtener una gran cantidad de información de sysstat y ayudarlo a descubrir qué sistema puede estar limitando el rendimiento general de la aplicación. En general, hiervo problemas de rendimiento en:
- pila de red
- pila de memoria
- disco io
- capa de aplicación
- capa os
Usando sysstat y otras herramientas, puede comenzar a dividir los pelos y encontrar el sistema que limita el rendimiento.
Por ejemplo, he visto fallar servidores muy cargados debido a cómo se configuró su aplicación. El almacenamiento en caché deficiente, la falta de encabezados caducados en contenido estático, el uso de HTTP frente a archivos incluidos, etc., todo contribuyó al bajo rendimiento de la aplicación. La solución de estos problemas de aplicación no requería cambios de hardware. En otros casos, he visto los discos al máximo a pesar de toneladas de almacenamiento en caché. Pasar a discos más rápidos solucionó el problema.
Enjuague y repita
A menudo, durante el ajuste de la aplicación, descorchará un cuello de botella para encontrar solo otro. Es por eso que recomiendo tratar de monitorear lo que sea que esté ajustando.
Por ejemplo, supongamos que soluciona un problema de E / S de disco pero su aplicación aún es lenta. Puede pensar que ha desperdiciado sus esfuerzos, pero lo que sucede es que simplemente está golpeando otro cuello de botella. Al monitorear el disco IO con cuidado, puede estar seguro de que está mejorando el disco IO incluso si sus importantes monitores de rendimiento de la aplicación no están cambiando.
Obtenga las herramientas adecuadas
Asegúrese de estar utilizando las herramientas adecuadas para el trabajo. El monitoreo, las pruebas, la evaluación comparativa, la creación de perfiles y otras técnicas de optimización tienen una variedad de herramientas. Encuentre la herramienta que mejor se adapte mejor a su situación.
Reglas de juego
Si bien cada aplicación es única, encuentro algunos puntos de partida estándar:
- bases de datos de memoria amor memoria
- el disco io cualquier cosa menos la incursión 10 puede matar el rendimiento de la base de datos
- optimizaciones incorrectas: los grandes valores no se traducen en un gran rendimiento
- aplicación: culpar al servidor por un diseño deficiente de la aplicación
Sus próximos pasos
Si no encuentra su cuello de botella, agregar un servidor puede no ser de gran ayuda. Para resolver el disco IO puede que necesite otro servidor o SAN. Si tiene un cuello de botella de ram, otro servidor resolverá el problema solo porque agrega más RAM. Movimiento bastante costoso en comparación con solo agregar más RAM a su servidor existente.
Arreglo rapido
Sobre despliegue. Tuve que hacer esto cuando parece que la pila de aplicaciones es el problema. Básicamente carga en CPU, RAM y disco IO (RAID 10, 15K SCSI o SSD). Vaya a lo grande en el hardware y luego comience a ajustar. Esto lo mantiene a flote hasta que resuelva los problemas.
