Webrick comme serveur de production vs. Thin ou Unicorn ?

Question

Il semble que l'on considère comme acquis que vous ne devez pas utiliser Webrick comme serveur de production, mais je ne trouve pas vraiment d'endroit mentionnant pourquoi. Le consensus semble être : "Webrick est ok pour le développement, mais Thin ou Unicorn est le choix à faire pour la production, point barre."

J'ai regardé la page d'accueil du serveur Thin et il est question de demandes/seconde mais je ne comprends pas vraiment le graphique puisqu'il n'y a pas d'annotation.

Quelqu'un peut-il me dire pourquoi je devrais utiliser Thin ou Unicorn plutôt que Webrick ? Y a-t-il un avantage à utiliser Webrick pour le développement ? J'utilise Webrick depuis qu'il est fourni avec rails, et je pense qu'il devrait y avoir une raison pour laquelle il est utilisé par défaut.

J'utilise Heroku d'ailleurs.

Answer 1

Quelques raisons importantes

1. il est écrit en Ruby (voir http://github.com/ruby/ruby/tree/trunk/lib/webrick )
2. Modifié il ne dispose pas de nombreuses fonctionnalités dont un site de production a généralement besoin, comme les travailleurs multiples (en particulier, le pré-forking, la gestion du cycle de vie, la gestion asynchrone, etc.), les redirections, la réécriture, etc.

Lorsque je mentionne les redirections/réécritures, je fais référence au fait qu'en utilisant Webrick, vous devez gérer les réécritures à une couche différente (Rack, Sinatra, Rails, code Webrick personnalisé, etc). Cela vous oblige à créer des "handlers" ruby supplémentaires pour exécuter votre code de réécriture. Pour un site à faible trafic, cela peut convenir car vous avez peut-être déjà des processus préchauffés qui ne font rien. Cependant, pour un site à fort trafic, c'est une charge supplémentaire sur le serveur pour quelque chose que les serveurs frontaux (Apache, Nginx, etc.) peuvent gérer sans faire tourner Ruby*, et probablement beaucoup plus rapidement.

* par exemple, si vous fonctionnez derrière un équilibreur de charge, vous pouvez acheminer tout le trafic de réécriture vers un serveur sur lequel ruby n'est pas installé, et laisser vos serveurs principaux gérer uniquement le trafic primaire. Ce trafic de réécriture peut être dû à des changements de site pour le référencement, ou quelque chose de similaire. Un autre cas serait un site qui a plusieurs composants, et peut-être une section est Rails, une autre est PHP, et les réécritures sont nécessaires pour les deux (c'est-à-dire réécrire les anciens chemins PHP vers Rails).

Answer 2

WEBrick ne peut pas non plus gérer les URI plus longs, s'ils dépassent 2083 caractères, vous verrez un crash. Thin n'a pas ces problèmes, ce qui le rend supérieur - déjà en développement.

Answer 3

Je n'aime pas vraiment compliquer les choses simples et l'optimisation prématurée. WEBrick peut être utilisé dans production à condition qu'il s'agisse plutôt d'un site à faible trafic. La plupart des applications le sont.

Si votre site fait quelque chose qui prend du temps, par exemple envoyer des e-mails ou générer des fichiers PDF, vous devez rendre WEBrick multi-threading . Vous souhaitez traiter plusieurs demandes à la fois.

Answer 4

Il a connu quelques problèmes de sécurité par le passé, mais il semble que la raison principale soit sa lenteur par rapport aux serveurs destinés à la production.

Answer 5

La plus grande faiblesse de webrick, lorsqu'il fonctionne en mode production, est qu'il s'agit d'un serveur web à file d'attente unique et à processus unique, ce qui signifie qu'il n'est capable de servir qu'une seule requête http à la fois.