ruby - utilizar - uso de memoria sql server
¿Es una mala idea crear subprocesos de trabajo en un proceso de servidor? (3)
Mi proceso de servidor es básicamente una API que responde a las solicitudes de REST.
Algunas de estas solicitudes son para iniciar tareas de larga ejecución.
¿Es una mala idea hacer algo como esto?
get "/crawl_the_web" do
Thread.new do
Crawler.new # this will take many many days to complete
end
end
get "/status" do
"going well" # this can be run while there are active Crawler threads
end
El servidor no manejará más de 1000 solicitudes por día.
No es la mejor idea ...
Utilice un corredor de trabajo en segundo plano para ejecutar trabajos.
POST /crawl_the_web simplemente debe agregar un trabajo a la cola de trabajos. El corredor de trabajo de fondo comprobará periódicamente si hay nuevos trabajos en la cola y los ejecutará en orden.
Puede utilizar, por ejemplo, el trabajo retrasado para esto, configurando un único proceso por separado para sondear y ejecutar los trabajos. Si está en Heroku, puede usar la función de retraso de trabajo para ejecutar los trabajos en un segundo trabajador / dyno independiente.
Si haces esto, ¿cómo piensas detener / reiniciar tu aplicación sinatra? Cuando finalmente implementes tu aplicación, tu aplicación probablemente será servida por unicorn, passenger / mod_rails, etc. Unicorn administrará el ciclo de vida de sus procesos secundarios y no tendría conocimiento de estos threads de larga ejecución que podrías haber lanzado y eso es un problema
Como alguien sugirió anteriormente, utilice demora_trabajo, resque o cualquier otro sistema basado en cola para ejecutar trabajos en segundo plano. Obtendrá la persistencia de los trabajos, obtendrá escalabilidad horizontal (simplemente inicie más trabajadores en más nodos), etc.
Iniciar hilos durante el proceso de solicitud es una mala idea.
Además de que no puede controlar sus subprocesos de trabajo (iniciar / detenerlos de forma controlada), rápidamente tendrá problemas si inicia un subproceso dentro del proceso de solicitud. Piense en lo que sucede: la solicitud finaliza y el proceso se prepara para atender la siguiente solicitud, mientras su hilo de trabajo todavía se ejecuta y accede a recursos globales de proceso como la conexión de base de datos, archivos abiertos, mismas variables de clase y variables globales, etc. Tarde o temprano, su hilo de trabajo (o cualquier biblioteca utilizada) afectará el hilo principal de alguna manera y romperá otras solicitudes, y será casi imposible depurarlo.
Realmente es mejor usar procesos de trabajo separados. retrayed_job, por ejemplo, es una dependencia realmente pequeña y fácil de usar.