ruby on rails - run - ¿Somos un servidor de producción frente a Thin o Unicorn?

ruby on rails puma server

Question

Parece que se da por sentado que no debe usar Webrick como servidor de producción, pero realmente no puedo encontrar ningún lugar que mencione por qué. El consenso parece ser: "Webrick está bien para el desarrollo, pero Thin o Unicorn es la opción para la producción, punto".

Busqué la página de inicio del servidor Thin y habla de solicitudes / segundo, pero realmente no entiendo el gráfico ya que no hay anotación.

¿Alguien puede decirme por qué debería usar Thin o Unicorn en comparación con Webrick? ¿También hay algún beneficio de usar Webrick para el desarrollo? He estado usando Webrick ya que viene con rieles, y creo que debería haber una razón por la cual está predeterminado.

Estoy usando Heroku por cierto.

Answer 1

La mayor debilidad de webrick cuando se ejecuta en modo de producción es que se trata de un único servidor web de proceso único, lo que significa que solo puede servir una única solicitud HTTP a la vez.

Answer 2

Realmente no me gusta complicar cosas simples y una optimización prematura. WEBrick se puede usar en producción siempre que sea un sitio web de poco tráfico. La mayoría de las aplicaciones son

Si su sitio hace algo que lleva tiempo, por ejemplo, envía correos electrónicos o genera archivos PDF, debe hacer que WEBrick se multiplique . Desea manejar múltiples solicitudes a la vez.

Answer 3

Un par de razones importantes

1. está escrito en Ruby (ver http://github.com/ruby/ruby/tree/trunk/lib/webrick )
2. Editado , no tiene muchas características que un sitio web de producción generalmente necesita, como varios trabajadores (en particular, prehorqueo, gestión del ciclo de vida, manejo asíncrono, etc.), redirecciones, reescritura, etc.

Cuando menciono redirecciones / reescrituras, me refiero al hecho de que al usar Webrick, debe manejar las reescrituras en una capa diferente (Rack, Sinatra, Rails, código Webrick personalizado, etc.). Esto requiere que generes "manipuladores" adicionales de rubí para realizar tu código de reescritura. Para un sitio de poco tráfico, esto puede estar bien, ya que es posible que los procesos precalentados no hagan nada. Sin embargo, para un sitio de mayor tráfico, esto es una carga adicional en el servidor para algo que los servidores front-end (Apache, Nginx, etc.) pueden manejar sin girar Ruby *, y probablemente órdenes de magnitud más rápidas.

* por ejemplo, si está ejecutando detrás de un equilibrador de carga, puede enrutar todo el tráfico de reescritura a un servidor que no tenga ruby ​​instalado, y permita que sus servidores principales solo administren el tráfico primario. Este tráfico de reescritura puede deberse a cambios en el sitio para SEO o algo similar. Otro caso sería un sitio que tiene múltiples componentes, y tal vez una sección es Rails, otra es PHP, y las reescrituras son necesarias para ambos (es decir, reescribir las antiguas rutas de PHP a Rails)

Answer 4

WEBrick tampoco puede manejar los URI más largos; si superan los 2083 caracteres, verá un bloqueo. Thin no tiene estos problemas, lo que lo hizo superior, ya está en desarrollo.

Answer 5

Ha tenido algunos problemas de seguridad en el pasado, pero parece que la gran razón es que es realmente lento en comparación con los servidores que están destinados a la producción.