Webrick comme serveur de production vs Thin ou Unicorn?
Il semble qu'il soit tenu pour acquis que vous ne devez pas utiliser Webrick comme serveur de production, mais je ne trouve vraiment nulle part où expliquer pourquoi. Le consensus semble être: "Webrick est ok pour le développement, mais Thin ou Unicorn est le choix pour la production, point final."
J'ai cherché la page d'accueil de Thin server et elle parle de requêtes/seconde mais je ne comprends pas vraiment le graphique car il n'y a pas d'annotation.
Quelqu'un peut-il me dire pourquoi je devrais utiliser Thin ou Unicorn par rapport à Webrick? Y a-t-il également un avantage à utiliser Webrick pour le développement? J'utilise Webrick depuis qu'il est livré avec Rails, et je pense qu'il devrait y avoir une raison pour laquelle c'est par défaut.
J'utilise Heroku d'ailleurs.
Quelques raisons importantes
- il est écrit en Ruby (voir http://github.com/Ruby/ruby/tree/trunk/lib/webrick )
- Modifié il n'a pas beaucoup de fonctionnalités dont un site de production a généralement besoin, comme plusieurs travailleurs (en particulier, le pré-forking, la gestion du cycle de vie, la gestion asynchrone , etc.), les redirections, la réécriture, etc.
Lorsque je mentionne des redirections/réécritures, je fais référence au fait qu'en utilisant Webrick, vous devez gérer les réécritures sur une couche différente (Rack, Sinatra, Rails, code Webrick personnalisé, etc.). Cela vous oblige à faire tourner davantage Ruby "gestionnaires" pour effectuer votre code de réécriture. Pour un site à faible trafic, cela peut être correct car vous pouvez avoir des processus préchauffés ne faisant rien déjà. Cependant, pour un site plus fréquenté, 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 des ordres de grandeur plus rapidement.
* par exemple, si vous utilisez un équilibreur de charge, vous pouvez acheminer tout le trafic de réécriture vers un serveur qui n'a pas Ruby installé, et laisser vos serveurs principaux gérer uniquement le trafic principal. 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 des réécritures sont nécessaires pour les deux (c'est-à-dire anciens PHP chemins vers Rails)
WEBrick ne peut pas non plus gérer des URI plus longs, s'ils dépassent 2083 caractères, vous verrez un plantage. Thin n'a pas ces problèmes, ce qui le rendait supérieur - déjà en développement.
Je n'aime pas vraiment compliquer les choses simples et l'optimisation prématurée. WEBrick peut être utilisé dans la production à condition qu'il s'agisse plutôt d'un site Web à faible trafic. La plupart des applications le sont.
Si votre site fait quelque chose qui prend du temps, par exemple envoie des e-mails ou génère PDF, vous devez créer WEBrick multi-thread . Vous souhaitez gérer plusieurs demandes à la fois.
Il a eu quelques problèmes de sécurité dans le passé, mais il semble que la grande raison en soit qu'il soit vraiment lent par rapport aux serveurs qui sont destinés à la production.
La plus grande faiblesse de webrick lors de son exécution en mode production est qu'il s'agit d'un serveur Web à processus unique et à thread unique, ce qui signifie qu'il n'est capable de servir qu'une seule requête http à la fois.