rails etc digitalocean deploy conf app ruby-on-rails nginx passenger

ruby-on-rails - etc - passenger nginx



La aplicaciĆ³n Rails alojada en el pasajero*dolorosamente*es lenta, pero el servidor es una bestia (2)

He estado trabajando para implementar una aplicación de Rails relativamente grande (Rails 2.3.5) y recientemente, al hacer algunas pruebas de carga, descubrimos que el rendimiento del sitio está muy por debajo del nivel de tráfico esperado.

Nos estábamos ejecutando en un servidor estándar de 32 bits, 3 GB de RAM con Centos, y estábamos ejecutando Ruby Enterprise Edition (última versión), Passenger (última versión) y Nginx (última versión), cuando solo hay uno o dos usuarios que el sitio ejecuta bien (como era de esperar), sin embargo, cuando tratamos de aumentar la carga a ~ 50 solicitudes concurrentes, muere completamente. (Informe de Apache Bench ~ 2.3 req / seg, que es terrible )

Estamos ejecutando RPM e intentando determinar dónde está el problema de carga, pero está distribuido de manera bastante uniforme en Rails, SQL y Memcached, por lo que estamos más o menos estudiando y optimizando la base de código.

Por pura desesperación armamos una gran instancia de EC2 (Ubuntu 9.10, 7.5GB RAM, 2 Compute Units / Cores) y configuramos la misma configuración que el servidor original, y aunque hay más recursos todavía estamos viendo resultados patéticos.

Entonces, después de pasar demasiado tiempo tratando de optimizar, jugando con la configuración de almacenamiento en caché, etc., decidí probar el rendimiento de algunos mongrels, y ta-da, están funcionando mucho mejor que Passenger.

Actualmente la configuración es de 15x Mongrex proxys a través de Nginx, y parece que estamos cumpliendo con nuestros requisitos de carga, pero no es suficiente para que me sienta cómodo con la puesta en marcha ... Lo que me preguntaba es si alguien sabe de algunas posibles causas para esto ...?

Mi configuración para pasajero / nginx era:

  • Trabajadores de Nginx: intentaron entre 1 y 10, generalmente tres sin embargo.
  • Tamaño máximo de la piscina del pasajero: 10 - 30 (sí, estos números son bastante altos)
  • Cola de espera global de pasajeros: intenté tanto encendido como apagado.
  • NGinx GZip encendido: sí

Vale la pena observar que hemos aumentado el tamaño del cuerpo del cliente nginx max a 200 m para permitir la carga de archivos de gran tamaño.

De todos modos, las sugerencias serían muy apreciadas, mientras que los mestizos están trabajando bien, cambia la forma en que hacemos las cosas y yo preferiría usar Passenger. Además, ¿no se suponía que esto facilitaría y funcionaría mejor?


Como primer paso, implementaría una aplicación de rieles de tipo "Hello World" mínima en su entorno y vería qué rendimiento obtiene con eso. Hacer eso al menos le dirá si su problema es con el medio ambiente o en algún lugar de su aplicación.


Tal vez su tamaño de grupo sql es demasiado pequeño? Esto limita esencialmente el paralelismo de las cargas de trabajo de la base de datos en su aplicación, que a su vez genera una carga mucho mayor tan pronto como pone el trabajo en la pila de su aplicación ...