¿Por qué mi sitio web sinatra es tan lento?

Question

Después de preguntar this question, comencé a usar Sinatra como una forma de servir páginas web.

Esta noche, un amigo mío y yo comenzamos a probar la velocidad del servidor.

El archivo para iniciar la sesión en el siguiente aspecto:

require 'rubygems' 
require 'sinatra' 
require 'haml' 

enable :sessions #for cookies! 

get '/' do 
    haml :index 
end 

Y el index.haml parece:

%title 
    First Page 

%header 
    %h2 First Page 

Está sentado en un ordenador portátil reciente, al igual que yo, con un 802.11n de Apple enrutador entre nosotros dos. Ambos estamos ejecutando Windows 7. También probé estos mismos archivos en una computadora portátil con Ubuntu 9.10 x64 con Sinatra y todos los archivos relevantes instalados desde apt-get.

Sinatra demora 7 segundos en servir una solicitud de una sola página, sin importar el sistema operativo del servidor, Windows o Linux. Veo que here el autor logró obtener más de 400 solicitudes/segundo procesadas. ¿Lo que da? (¿o debería estar en SuperUser o similar?)

Answer 1

I' Dejaré de lado cualquier opinión sobre cuándo debería optimizar su aplicación web.

Configure diferentes configuraciones en su aplicación Sinatra para desarrollo y producción porque algunas de estas sugerencias, no siempre querrá usar. De hecho, probablemente debería seguir adelante y configurar y un entorno similar a cómo se implementaría en la producción. No implementaría simplemente ejecutando ruby app.rb. Te gustaría poner apache o nginx delante de tu Mongrel. Mongrel servirá tus archivos estáticos, pero eso solo es recomendable para el modo de desarrollo. En la implementación, un servidor web hará un trabajo mucho mejor para eso. En resumen, su entorno desplegado será más rápido que su entorno de desarrollo independiente.

En este punto, no me preocuparía por Mongrel vs. Thin. Si Thin es dos veces más rápido, no lo es, tus 7 segundos se convierten en 3.5. ¿Será eso lo suficientemente bueno?

Algunas cosas para probar ...

Sé que acabo de decir a configurar un entorno de despliegue, pero tal vez no es el lado del servidor. ¿Has intentado ejecutar YSlow o PageSpeed en tus páginas? La E/S va a ocupar más de esos 7 segundos (Descargo de responsabilidad: asumo que no hay nada de malo en la configuración de su red) que el servidor. YSlow - Firebug en realidad - le dirá cuánto tiempo lleva cada parte de su página para llegar al navegador.

Una de las cosas que YSlow me dijo que hiciera fue colocar un encabezado Expires muy adelantado en mis activos estáticos, lo cual supe pero estaba dejando la optimización hasta el final. Fue entonces cuando me di cuenta de que había al menos 3 different places that I could specify that header. Me estoy convenciendo de que hacerlo en nginx es el lugar adecuado para expresarlo.

Si está contento con esos resultados, entonces puede mirar el servidor. Fuera de mi cabeza, por lo que no es exhaustivo

1. Activar las respuestas de gzip.
2. Combina tus hojas de estilo para que solo haya una solicitud por página. Puede haber algo de Middleware Rack para esto, si no lo haces manualmente.
3. Caché. Estoy intentando Rack::Cache.
4. Usa sprites para disminuir el número de descargas de imágenes que usas.
5. Minifica tu Javascript. Nuevamente, tal vez a través de Rack Middleware.

Rack Middleware está ordenado, pero usa CPU. Por lo tanto, minificar manualmente su Javascript agrega un nuevo paso a su flujo de trabajo, pero en el servidor, es más rápido que Middleware. Es una compensación.

Disculpe si esto fue rambly.

Answer 2

Intente utilizar Thin como el servidor. Noté un aumento en el rendimiento en comparación con WEBrick y Mongrel.

gem install thin 

Al ejecutar la aplicación usando ruby TestServer.rb verá lo siguiente:

Sinatra/0.10.1 ha tomado el escenario en 4567 para el desarrollo con el respaldo de Thin

Answer 3

Tuve este problema al ejecutar Sinatra con escopeta pero no al ejecutar mi aplicación directamente (es decir, ruby -rubygems app.rb). Esto se debe a que la escopeta se bifurca y vuelve a cargar la aplicación para cada solicitud.

Encontré un thread in Sinatra's mailing list que discutió este problema y la gente allí aconsejó usar rerun en lugar de escopeta. Me complace decir que resolvió este problema para mí.

Answer 4

Estoy ejecutando Sinatra dentro de VMWare Fusion con Vagrant. Mi aplicación se estaba ejecutando lentamente (unos diez segundos para atender una solicitud). Entonces me encontré con esta joya:

Webrick is very slow to respond. How to speed it up?

Parece que fue WEBrick (por defecto) configurado para la búsqueda inversa DNS en cada petición, y que estaba disminuyendo su velocidad.