¿Webrick como servidor de producción frente a Thin o Unicorn?

117

Parece que se da por sentado que no debe usar Webrick como servidor de producción, pero realmente no puedo encontrar en 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 anotaciones.

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

Por cierto, estoy usando Heroku.

— Vlad
fuente

Es lento en comparación con otros como Mongrel.

— uday

38

Ken, realmente no hice esta pregunta para debatir nada. Realmente quiero saber la respuesta porque no pude encontrar estadísticas reales en ningún lado, cuando todos dan por sentado que Webrick es inferior. No estoy afiliado a ninguno de esos partidos y los debates que mencionaste son preguntas que hago por verdadera curiosidad. ¿Cómo puedo reformular la pregunta para que no se vea de esa manera?

— Vlad

24

Esta es una buena pregunta.

— justingordon

29

Preguntas como esta NO deben cerrarse. Son útiles y útiles. Toda la policía de contenido autoproclamada debe retroceder.

— Ken Smith

22

Encontré esto buscando en Google "¿Por qué no usar WEBrick en producción?" porque es una pregunta que quiero respuesta. No me refiero a utilizar WEBrick en la producción, pero me molesta que todo el mundo diga: "Porque no es For Production®, obviamente". Realmente no es tan obvio; si lo fuera, la gente no estaría investigando la pregunta antes de preguntar finalmente en StackOverflow, como @Vlad indica que lo hizo. La respuesta aceptada es útil; al menos señala algunas características que faltan. Tangencialmente, insistir en que se cierre una pregunta porque cree que es discutible sin proporcionar su propia respuesta no es útil.

— Justin Force

42

Un par de razones importantes

está escrito en Ruby (ver http://github.com/ruby/ruby/tree/trunk/lib/webrick )
Editado no tiene muchas características que un sitio web de producción generalmente necesita, como múltiples trabajadores (en particular, pre-bifurcación, administración del ciclo de vida, manejo asincrónico, etc.), redirecciones, reescritura, etc.

Cuando menciono redirecciones / reescrituras, me refiero al hecho de que al usar Webrick, debes manejar las reescrituras en una capa diferente (Rack, Sinatra, Rails, código personalizado de Webrick, etc.). Esto requiere que active "manejadores" ruby adicionales para realizar su reescritura de código. Para un sitio con poco tráfico, esto puede estar bien, ya que es posible que ya tenga procesos precalentados que 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 hacer girar Ruby *, y probablemente órdenes de magnitud más rápido.

* por ejemplo, si se 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 dejar que sus servidores principales solo administren el tráfico principal. 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 varios componentes, y tal vez una sección es Rails, otra es PHP, y se necesitan reescrituras para ambos (es decir, reescribir las antiguas rutas de PHP a Rails)

— Jim Deville
fuente

¿No es posible usar delayed_job para manejar varios trabajadores en Heroku, independientemente del servidor que use?

— Vlad

Sí, delayed_job no está relacionado con Webrick, a menos que sus trabajos utilicen las API de Webrick (que honestamente es un olor a código cuando se acopla).

— Jim Deville

Me refiero a redirecciones fuera de la pila de Ruby. Como redireccionamientos de estilo mod_rewrite. Técnicamente, puede redirigir dentro de Rack, o Rails, o, tal vez incluso Webrick (podría estar equivocado), pero eso requiere iniciar ruby, que es comparativamente lento frente a Apache o Nginx

— Jim Deville

1

@JimDeville - Unicornio también está escrito en Ruby

— Yarin

1

github.com/defunkt/unicorn/tree/master/ext/unicorn_http una gran parte de Unicorn está en C

— Jim Deville

4

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

— Michael Schmitz
fuente

También Webrick perdió la conexión y se apagó automáticamente cuando, según mi experiencia, estoy desarrollando software y cuando elegí WeBRICK en Heroku PaaS, el apagado automático se compensa con la alta velocidad de encendido automático (disparado a través de la arquitectura automática de Heroku )

— Daniel Antonio Nuñez Carhuayo

3

Realmente no me gusta complicar las cosas simples y la optimización prematura. WEBrick se puede utilizar 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 sea multiproceso . Quieres manejar varias solicitudes a la vez.

— Nowaker
fuente

1

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

— Brett Henning
fuente

4

¿Has visto una comparación de estadísticas? También escucho a la gente decir eso (y probablemente sea cierto) pero no puedo encontrar una comparación de estadísticas reales en ninguna parte de la web ...

— Vlad

3

No creo que nadie realmente evalúe Webrick porque no está destinado a ser un servidor de producción. Unicornio, Thin o Passenger están bien respaldados y son opciones mucho mejores

— Jim Deville

0

La mayor debilidad de webrick cuando se ejecuta en modo de producción es que es un servidor web de proceso único y de un solo proceso, lo que significa que es capaz de atender solo una solicitud http a la vez.

— Artur Beljajev
fuente

No es de un solo hilo. O es de la misma manera que se implementa cualquier lenguaje de escritura moderno (con un GIL). Pero el acceso a la base de datos y la E / S en webrick es completamente multiproceso.

— Lothar