2010-05-21 24 views
5

¿cómo se puede depurar con eficacia en el servidor activo en raíles, ya sea en un servidor de producción/beta?Depuración en el servidor de producción en Rails

he intentado modificar el archivo directamente en el servidor, y reiniciar la aplicación, pero no parece que los cambios surtan efecto, o tarda mucho tiempo a la escritura (almacenamiento en caché?)

También probé a hacer "/server production "localmente, pero eso es muy lento

La otra opción es codificar e implementar, pero eso es muy ineficiente.

¿Alguien tiene alguna idea de cómo lo hacen de manera eficiente?

Respuesta

7

voy a responder a su pregunta, aunque no estoy de acuerdo con esta forma de Hotpatching el código del servidor :)

En primer lugar, ¿está realmente seguro de que ha reiniciado el servidor? Puede verificarlo siguiendo los archivos de registro.

La vista que se muestra por su código modificado puede almacenarse en caché. Las páginas en caché se encuentran en la carpeta tmp/cache. Puede intentar eliminar manualmente el archivo o puede rake tmp:cache:clear y todos serán eliminados. De todos modos, puede ver exactamente lo que está sucediendo al rastrear su archivo log/production.log (le dirá algo así como 'representación en caché ...').

Otro punto: algunos datos también se almacenan en la sesión. También puede intentar eliminar su sesión (o eliminar todas las sesiones; por ejemplo, si mantiene sus sesiones en DB, puede ejecutar rake db:sessions:clear)

+0

grandes consejos: 1) archivos de registro del tizón (puedo mestizo cola registra también) 2) rastrillo tmp: cache: clear (GRACIAS) PS: Yo uso CODA para editar directamente el código de servidor de ensayo. =) –

2

Para ejecutar el servidor local en el modo de producción, probar:

RAILS_ENV=production script/server 

o

script/server --environment=production 

El problema es que, a menos que también está utilizando el servidor WEBrick/mestizo en la producción real, Al hacerlo, no se duplicará exactamente la configuración de producción real (presumiblemente utilizando Apache o Passenger?). También podría haber diferencias sutiles en los entornos que podrían estar causando sus problemas.

¿Cómo está reiniciando su entorno de producción cuando cambia las cosas allí? esto depende de cómo se implementó, y podría ser tan simple como soltar un restart.txt en/tmp de su aplicación, o tan difícil (no realmente) como reiniciar Apache o los procesos de Mongrel que sirven a su aplicación. Parece extraño que los cambios tarden mucho en aparecer cuando haces esto.

Cuando surge un problema en el modo de producción, solo compruebo el archivo production.log que generalmente me apunta en la dirección de una solución. Implemento esto en desarrollo y luego vuelvo a implementarlo. Eso generalmente se ocupa de las cosas. El uso de Capistrano solo requiere 3 comandos (un commit, un push y un deploy), a menos que su configuración sea significativamente más compleja que la mía.

+0

¿Qué quiere decir con restart.txt? Mi configuración también es simple, pero el problema es que a veces necesito DEPURAR usando el entorno de producción, lo que significa que debo hacerlo a menudo. =) –

+0

en Passenger (un módulo Apache para implementación de rails) reinicia la aplicación creando un archivo restart.txt en el directorio/tmp de la aplicación. Consulte la documentación aquí: http://www.modrails.com/documentation/Users%20guide.html # _redeploying_restarting_the_rack_application – Roadmaster

Cuestiones relacionadas