2009-05-26 8 views
5

siempre la primera petición (de una sesión de trabajo) a mi aplicación Rails se está quedando. Cambiar al modo de producción no ayuda.primera petición a Rails aplicación es muy lento

utilizo mestizo y las otras peticiones son manejadas con una velocidad aceptable.

¿Cómo puedo hacer que sea más rápido?

Saludos

Respuesta

1

En caso de publicar el contenido del registro como la primera petición se procesa entonces tal vez podamos averiguar lo que está haciendo es tan lento. Por ejemplo, este es mi registro como el primer usuario accede al sitio

Booting Mongrel (use 'script/server webrick' to force WEBrick)  
Rails 2.1.0 application starting on http://0.0.0.0:3000  
Debugger enabled  
Call with -d to detach  
Ctrl-C to shutdown server 
** Starting Mongrel listening at 0.0.0.0:3000 
** Starting Rails with development environment... 
/usr/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/mime_type.rb:66: warning: already initialized constant CSV 
** Rails loaded. 
** Loading any Rails specific GemPlugins 
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). 
** Rails signals registered. HUP => reload (without restart). It might not work well. 
** Mongrel 1.1.5 available at 0.0.0.0:3000 
** Use CTRL-C to stop. 


Processing SessionsController#new (for 127.0.0.1 at 2009-05-26 12:26:00) [GET] 
    Session ID: de2acf074759026e1ed6205724f547a9 
    Parameters: {"action"=>"new", "controller"=>"sessions"} 
Rendering sessions/new 
Completed in 0.00587 (170 reqs/sec) | Rendering: 0.00298 (50%) | DB: 0.00092 (15%) | 200 OK [http://localhost/] 

Creo reqs 170/seg está muy bien para nuestra aplicación pero otros pueden encontrar que lento. Puede ver en las estadísticas que Rails proporciona que la mitad del tiempo requerido se gasta al procesar la respuesta, en este caso generando el HTML para la pantalla de inicio de sesión. Si esta solicitud tardaba mucho tiempo, mi primer puerto de escala serían las vistas y los ayudantes asociados con la pantalla de inicio de sesión.

Si tiene un sistema que tarda mucho tiempo en inicializarse en la primera solicitud, ¿por qué no ser astuto y escribir su propio programa de inicio que primero ejecuta raíles y luego envía una solicitud falsa en curl. De esa forma, tus usuarios nunca verán el problema.

Chris

+0

Gracias por su pista. Aquí está mi archivo de registro: http://pastie.org/private/ih2mpcmjpofp5jmfsvw A veces, dura mucho más de 1600 ms para responder a mi solicitud. Realmente no tengo ni idea ... – Stefan

+1

¿Qué versión de rieles estás usando? Completado en 10367ms (Vista: 1572, BD: 450) | 200 OK [http: // localhost/search? Search = stefan +] Parece que lleva 10 segundos responder a la primera solicitud. Supongo que volver a buscar la misma pregunta "stefan" es mucho más rápido. ¿Cuánto tiempo lleva encontrar un registro diferente? Finalmente, ¿cuánto tiempo lleva buscar un registro inexistente? –

1

Puede ser la misma razón que nuestras aplicaciones tomando mucho tiempo la primera vez que ellos comenzará en Websphere.

ERA tiene que hacer un montón de trabajo inicial para establecer los contenedores cuando se instala una nueva versión de la aplicación (¿o se reinicia).

La solución alternativa que utilizamos fue modificar los scripts de instalación y los scripts de inicio de WAS para que navegaran automáticamente a la aplicación (página principal y otras páginas seleccionadas) tan pronto como se ejecutara. De esa forma, el primer acceso real a él fue a toda velocidad.

que no tienen idea de cómo hacer esto con Ruby o incluso si es posible. Tendrás que descubrirlo.

+0

Es posible: puede usar una secuencia de comandos simple para solicitar una página de todas las aplicaciones de rieles utilizando curl/wget para lograr el mismo efecto. – Petesh

1

supongo que está utilizando hurón para búsqueda de texto completo? ¿Será que la conexión del hurón tarda un rato en inicializarse? Cuando reviso su registro, parece que tanto el db como la vista toman una cantidad de tiempo normal, pero el total sigue siendo de 10 segundos. Así que debo ser otra cosa. Es por eso que supongo que Ferret podría ser el problema.

1

Puede ser porque eres:

  • que requiere y la carga de una serie de plugins y gemas

  • realizar una conexión a un servicio externo (entonces el almacenamiento en caché)

  • almacenando en caché sus propias páginas y que solo se produce después de la primera solicitud a menos que 'caliente' el caché

Cualquiera de ellos es inevitable aumentar el tiempo de respuesta de la primera petición.

0

Quizás necesite ajustar PassengerPoolIdleTime var en apache conf. Establézcalo en 0 para nunca detener el proceso de los rieles.