ruby - utilizar - uso de memoria sql server

¿Es una mala idea crear subprocesos de trabajo en un proceso de servidor?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.