¿Ajuste de rendimiento de rieles para producción?

Question

Me estoy acercando a la implementación de una aplicación basada en Rails 3.1.x y comencé a ejecutar algunas pruebas de rendimiento. Después de jugar un poco con ab, estoy viendo algunos resultados muy desalentadores dando alrededor de 15 solicitudes/segundo en Heroku.

Al realizar pruebas locales, veo resultados similares que realmente demuestran que es un problema de aplicación más que cualquier otra cosa.

Estoy ejecutando Unicorn, que es aproximadamente un 40% más rápido que Thin en Celadon Cedar. Además, estoy usando el db compartido de PGSQL.

Tengo la esperanza de que alguien pueda compartir una lista de lavandería o, esencialmente, una lista de comprobación de lanzamiento que debería seguir cuando preparo una aplicación para producción y cambie la necesidad de ajustar la velocidad. Hasta ahora he no encontré una lista concisa real de elementos procesables para moverse que parece tener sentido dada mi situación.

O si tiene una sólida experiencia práctica en este tipo de cuestiones, ¡se agradecerá cualquier comentario!

Answer 1

Pasé algún tiempo ajustando mi aplicación en heroku y pasé un tiempo trabajando en la optimización del rendimiento de las aplicaciones de Rails en una variedad de configuraciones.

Cuando corro ab -n 300 -c 75 ... .... # myapp.com que es una copia de seguridad de mi sitio principal, y está en el plan de cedro gratuita 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 está en contra de una página de inicio que no hace nada intenso, así que solo la proporciono como "¿qué tan rápido podría heroku estar en el plan gratuito con una página muy simple?" ejemplo, no una "tus aplicaciones deben ser esta rápida ")

Aquí es mi rieles Ajuste de rendimiento 101 lista de comprobación:

1. Mida primero el tiempo de carga del navegador/página (el navegador realiza muchas solicitudes, ab solo le informa sobre uno de ellos, y generalmente su solicitud de página principal no es el problema), obtenga números de referencia de carga de página de herramientas como www.webpagetest.org o www.gtmetrix.com para las páginas públicas, o las herramientas del navegador Yslow, la velocidad de la página de google o dynatrace para las páginas privadas. Si miras el diagrama de cascada de carga de página (el panel 'Net' en chrome/firefox), generalmente muestra que tu html se carga rápidamente (menos de un segundo), pero luego todo lo demás tarda 1-3 segundos en cargarse. Siga las recomendaciones de Yslow/velocidad de página sobre cómo mejorar (asegúrese de estar utilizando todo el material de la línea de recursos de Rails 3.1)

2. Lea sus archivos de registro/nueva reliquia para encontrar el punto óptimo de la 'más lenta/la mayoría de las veces aciertan 'solicitud, y el perfil de lo que sucede para esa solicitud (¿es lento ruby ​​/ mucho uso de mem, o muchas consultas?) Necesita tener una manera confiable de detectar y monitorear problemas de rendimiento, y no solo ir cambiando 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 entra una regresión.

3. La falta de índices en columnas db es una de las más comunes problemas, y más fácil de abordar. Ejecuta explicaciones en las consultas de destino o consulta el registro lento de consultas para ver qué está haciendo el planificador de consultas. Agregue índices para claves externas, columnas de búsqueda o datos primarios (que cubren el índice) según corresponda. Vuelva a evaluar con los datos de producción reales para demostrar que hace la diferencia. (Puede ejecutar Explain en heroku, así como ejecutar consultas para índices faltantes o no utilizados)

4. La mayoría de las aplicaciones de Rails de bajo rendimiento sufren de N + 1 consultas porque es muy fácil escribir order.owner.address.city y no piensa en lo que sucede cuando todo está en un bucle.Las consultas N + 1 no son necesariamente consultas lentas, por lo que no se muestran en el registro lento de consultas, 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 hacia adelante y hacia atrás 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, les proporcionaría los datos que necesitan de una manera más rápida. Escribí algunos more thoughts about that on my blog

hice una presentación sobre estas técnicas y otras ideas en Chicago en la conferencia WindyCityRails de este año. Puedes see the video here on my www.RailsPerformance.com blog Lo que me encanta de Heroku es que tienes que ser escalable desde el principio. Cuando mira las discusiones en la lista de correo, ve que la mayoría de la gente conoce las mejores prácticas de rendimiento y cómo aprovechar al máximo el servidor. También me gusta cómo si quieres mantenerte barato, aprendes cómo funcionan los trucos de ajuste de rendimiento que te sacarán el máximo partido.

¡Buena suerte!

Answer 2

Como nada ha salido aún, daré una respuesta para la parte PostgreSQL. No puedo ayudar con Ruby.

Puede encontrar excelentes puntos de partida para optimizar el rendimiento en la wiki de PostgreSQL.

• Ajuste del server settings (no estoy seguro de cuánto es posible con Heroku)
• Prestar especial atención a slow queries
• Compruebe su hardware (no aplicable con Heroku)

Answer 3

La más completa respuesta única es usar algo como NewRelic para instrumentar su aplicación y encontrar los puntos lentos. Luego, puede aplicar optimizaciones o almacenamiento en caché a su código para suavizar esos puntos lentos. Como cliente de Heroku, obtiene una instalación de NewRelic gratis, es un complemento que puede agregar a su implementación desde la consola de Heroku.

Una vez que comprenda qué es lo que le está ralentizando, entonces puede comenzar a acercarse a él. Heroku maneja la mayoría de todos los desarrolladores al final del ajuste del rendimiento, por lo que no necesitas hacer nada allí. Sin embargo, aún podrá obtener grandes ganancias al optimizar las consultas de la base de datos y realizar el almacenamiento en caché de fragmentos y acciones cuando corresponda.

Answer 4

Hay un poco de fruta muy baja altura que casi siempre producen mejoras de rendimiento bastante dignos:

1. Reducir el número de consultas de base de datos mediante el uso de declaraciones de ActiveRecord más eficientes. Asegúrese de utilizar include y join cuando corresponda, y asegúrese de estar utilizando empty? en any? donde sea posible para evitar SELECT s cuando solo necesite COUNT.
2. Especialmente en páginas más pesadas, vistas de caché, aunque solo sea por unos minutos. A menudo puede dividir piezas más grandes o dinámicas en parciales que pueden almacenarse en caché sin ningún efecto negativo.
3. Mueva cualquier actividad de la red a trabajos en segundo plano. Esto incluye enviar correos electrónicos, buscar páginas del sitio web de anteras y hacer llamadas a la API (¿incluso [especialmente?] A Heroku).Hay una cantidad de bibliotecas de procesamiento de trabajos en segundo plano realmente buenas en Ruby, DelayedJob es muy popular porque funciona con cualquier base de datos ActiveRecord, pero mi favorito es Resque.

Debe tener cuidado de no perder demasiado tiempo optimizando las rutinas de Ruby. A menos que esté haciendo algo con una gran cantidad de datos o procesamiento (por ejemplo, cambio de tamaño de la imagen), probablemente no verá ganancias muy significativas al optimizar bucles o minimizar el uso de la memoria. Y si encuentra que ciertas páginas son problemáticas, explore sus registros y vea qué está sucediendo durante esas solicitudes.

Y si no lo está haciendo todavía, las aplicaciones de escalado automático como HireFireApp son excelentes para permitirle manejar una gran cantidad de solicitudes escalando horizontalmente sin el costo de ejecutar dinnos extraños durante períodos lentos.

PD: Hay un nuevo Add-On de Heroku llamado Blitz que le permite probar una carga concurrente de hasta 5,000 usuarios.