¿Sinatra tiene múltiples hilos?

Question

¿Sinatra tiene varios hilos? Leí más sobre dónde ese "sinatra tiene varios subprocesos por defecto", ¿qué implica eso?

Considere este ejemplo

get "/multithread" do 
    t1 = Thread.new{ 
    puts "sleeping for 10 sec" 
    sleep 10 
    # Actually make a call to Third party API using HTTP NET or whatever. 
    } 
    t1.join 
    "multi thread" 
end 

get "/dummy" do 
    "dummy" 
end 

Si accedo "/ multi-hilo" y "/ ficticio" posteriormente en otra pestaña o el navegador entonces nada puede ser servida (en este caso por 10 segundos) hasta "/ multi-hilo" la solicitud esta completa En caso de que la actividad se congele, la aplicación deja de responder.

¿Cómo podemos evitar esto sin generar otra instancia de la aplicación?

Answer 1

tl; dr Sinatra funciona bien con Threads, pero es probable que deba utilizar un servidor web diferente.

Sinatra en sí mismo no impone ningún modelo de simultaneidad, ni siquiera maneja la simultaneidad. Esto lo hace el manejador de Rack (servidor web), como Thin, WEBrick o Passenger. Sinatra en sí mismo es seguro para subprocesos, lo que significa que si su controlador de Rack usa varios subprocesos para las solicitudes del servidor, funciona bien. Sin embargo, dado que Ruby 1.8 solo admite subprocesos verdes y Ruby 1.9 tiene un bloqueo de VM global, los subprocesos no son muy utilizados para la simultaneidad, ya que en ambas versiones, los subprocesos no se ejecutarán verdaderamente en paralelo. La voluntad, sin embargo, en JRuby o el próximo Rubinius 2.0 (ambas implementaciones alternativas de Ruby).

La mayoría de los racks existentes que usan hilos usarán un grupo de subprocesos para volver a utilizar los subprocesos en lugar de crear un subproceso para cada solicitud entrante, ya que la creación de subprocesos no es gratis, esp. en 1.9 donde los hilos mapean 1: 1 a hilos nativos. Los hilos verdes tienen mucha menos sobrecarga, razón por la cual las fibras, que básicamente son hilos verdes programados cooperativamente, tal como se utilizaba en la sinatra-sincronía antes mencionada, se volvieron tan populares recientemente. Debe tener en cuenta que cualquier comunicación de red tendrá que pasar por EventMachine, por lo que no puede usar la gema mysql, por ejemplo, para hablar con su base de datos.

Las fibras se adaptan bien para el procesamiento intensivo de la red, pero fallan miserablemente en cálculos pesados. Es menos probable que te encuentres en condiciones de carrera, una trampa común con concurrencia, si usas fibras, ya que solo hacen un cambio de contexto en puntos claramente definidos (con sincronización, cada vez que esperas IO). Hay un tercer modelo de concurrencia común: Procesos. Puede usar el servidor de precompresión o iniciar múltiples procesos usted mismo. Si bien esto parece una mala idea a primera vista, tiene algunas ventajas: en la implementación normal de Ruby, esta es la única forma de usar todas sus CPU al mismo tiempo. Y evita el estado compartido, por lo que no hay condiciones de carrera por definición. Además, las aplicaciones multiproceso se escalan fácilmente en varias máquinas. Tenga en cuenta que puede combinar procesos múltiples con otros modelos de concurrencia (evented, cooperative, preventive).

La elección se hace principalmente por el servidor y middleware que utilice:

• multi-proceso, no preforking: Mestizo, Fino, WEBrick, Zbatery
• Multi-Proceso, preforking: unicornio, arco iris , Pasajero
• evented (adecuado para Sinatra-sincronía): Thin iris, Zbatery
• Threaded: Net :: HTTP :: Server, roscado Mongrel, Puma, arco iris, Zbatery, Thin [1], Phusion Passenger Enterprise >= 4

[1] desde Sinatra 1.3.0, Thin se iniciará en modo enhebrado, si es iniciado por Sinatra (es decir, con ruby app.rb, pero no con el comando thin, ni con rackup).

Answer 2

Mientras que alrededor de google, encontramos esta joya:

sinatra-synchrony

que podría ayudar, porque toca usted pregunta.

También hay un punto de referencia, hicieron casi lo mismo que desea (llamadas externas).

Conclusión: ¡EventMachine es la respuesta aquí!

Answer 3

Después de hacer algunos cambios en el código, pude ejecutar la aplicación padrino/sinatra en mizuno . Inicialmente traté de ejecutar la aplicación Padrino en jRuby pero era demasiado inestable y no investigué por qué. Estaba enfrentando bloqueos JVM cuando se ejecuta en jRuby. También revisé el artículo this, lo que me hace pensar por qué incluso elegir Ruby si la implementación puede ser cualquier cosa menos fácil.

¿Hay alguna discusión sobre el despliegue de aplicaciones en ruby? ¿O puedo generar un nuevo hilo :)

Answer 4

Llegué últimamente a JRuby y estoy muy sorprendido de lo simple que es pasar de MRI a JRuby. Prácticamente implica cambiar algunas gemas (en la mayoría de los casos).

Debería echar un vistazo a la combinación JRuby y Trinidad (servidor de aplicaciones). Torquebox también parece ser una solución todo en uno interesante, viene con mucho más que solo un servidor de aplicaciones.

Si desea tener un servidor de aplicaciones que admite el enhebrado, y esté familiarizado con Mongrel, Thin, Unicorn, etc., entonces Trinidad es probablemente la más fácil de migrar ya que es prácticamente idéntica desde la perspectiva de los usuarios. ¡Lo amo hasta ahora!

Answer 5

Pensé que podría elaborar para las personas que se encuentran con esto. Sinatra incluye este pequeño trozo de código:

server.threaded = settings.threaded if server.respond_to? :threaded=  

Sinatra detectará qué joya que haya instalado un servidor web (también conocido como, delgada, el puma, lo que sea.) Y si responde a una "rosca" a configurarlo para ser roscado si se solicita. Ordenado.