sql >> Base de Datos >  >> RDS >> PostgreSQL

¿Ajuste del rendimiento de Rails para la producción?

Pasé un tiempo ajustando mi aplicación en heroku y trabajando en el ajuste del rendimiento de las aplicaciones de Rails en una variedad de configuraciones.

Cuando ejecuto ab -n 300 -c 75 ...myapp.com.... # que es una copia de seguridad de mi sitio principal y está en el plan de cedro gratuito con unicornio

Requests per second:    132.11 [#/sec] (mean)
Time per request:       567.707 [ms] (mean)
Time per request:       7.569 [ms] (mean, across all concurrent requests)

(esto va en contra de una página de inicio que no hace nada intenso, así que lo proporciono solo como un ejemplo de "¿qué tan rápido podría ser heroku en el plan gratuito con una página muy simple?", no como un ejemplo de "tus aplicaciones deberían ser así de rápido")

Esta es mi lista de verificación de Rails Performance Tuning 101:

  1. Mida primero el tiempo de carga del navegador/página (el navegador hace muchas solicitudes, ab solo le informa sobre una de ellas y, por lo general, la solicitud de su página principal no es el problema), obtenga los números de referencia de carga de la página de herramientas como www.webpagetest.org o www.gtmetrix.com para las páginas públicas, o las herramientas de navegación Yslow, Google Page Speed ​​o Dynatrace para las páginas privadas. Si observa el diagrama de cascada de carga de la página (el panel 'Neto' en Chrome/Firefox), generalmente muestra que su html se carga rápidamente (menos de un segundo), pero todo lo demás tarda de 1 a 3 segundos en cargarse. Siga las recomendaciones de Yslow/velocidad de página sobre cómo mejorar (asegúrese de que está utilizando la canalización de recursos de Rails 3.1 en toda su extensión)

  2. Lea sus archivos de registro/nueva reliquia para encontrar el punto óptimo de la solicitud 'más lenta/acertada con mayor frecuencia' y perfile lo que sucede con esa solicitud (¿es lento Ruby/mucho uso de memoria o muchas consultas?) para tener una forma confiable de detectar y monitorear problemas de rendimiento, y no solo ir cambiando las cosas al azar. Una vez que haya identificado algunas áreas objetivo, cree scripts de prueba para ayudar con las pruebas antes/después y demuestre que su cambio ayuda, y detecte si se produce una regresión.

  3. La falta de índices en las columnas de la base de datos es uno de los problemas más comunes y más fáciles de abordar. Ejecute la explicación en las consultas de destino, o mire a través de su registro de consultas lentas, para ver qué está haciendo el planificador de consultas. Agregue índices para claves foráneas, columnas de búsqueda o datos primarios (índice de cobertura), según corresponda. Vuelva a probar con datos de producción reales para demostrar que marca la diferencia. (puede ejecutar la explicación en heroku, así como ejecutar consultas para índices faltantes o no utilizados)

  4. La mayoría de las aplicaciones Rails de bajo rendimiento sufren consultas N+1 porque es muy fácil escribir order.owner.address.city y no pensar en lo que sucede cuando está en un bucle. Las consultas N+1 no son necesariamente consultas lentas, por lo que no aparecen en el registro de consultas lentas, es solo que hay muchas y es más eficiente hacerlo todo a la vez. Use :include o .includes() para la carga ansiosa de esos datos, o busque hacer su consulta de otra manera.

  5. Analice el flujo de su aplicación y busque oportunidades de almacenamiento en caché. Si el usuario rebota de un lado a otro entre la página de índice y una página de detalles, y viceversa, tal vez una vista ajax de los detalles, sin salir de la página de índice, le brindaría los datos que necesita de una manera más rápida. Escribí algunas más ideas sobre eso en mi blog

Hice una presentación sobre estas técnicas y otras ideas en Chicago en la conferencia WindyCityRails de este año. Puede ver el video aquí en mi www.RailsPerformance blog .com Lo que me encanta de heroku es que tienes que ser escalable desde el principio. Cuando observa las discusiones en la lista de correo, ve que la mayoría de las personas conocen las mejores prácticas de rendimiento y cómo aprovechar al máximo el servidor. También me gusta cómo, si quieres seguir siendo económico, aprendes los trucos de ajuste de rendimiento que te sacarán el máximo partido.

¡Buena suerte!