Unicorn est compatible avec Rack, une interface entre les serveurs applicatifs et les frameworks. Il peut ainsi être utilisé pour servir des applications Ruby, dont celles écrites en Ruby on Rails. Il tourne avec Ruby 1.8, Ruby 1.9 et bientôt Rubinius. Rappelons que Rubinius est une implémentation alternative de Ruby dont la version 1.0 est sortie récemment.
Unicorn s'appuie au maximum sur les noyaux Unix pour éviter de réinventer la roue. Par exemple, la répartition des requêtes entre les différents processus se fait grâce à une socket partagée. Il est également possible de mettre à jour Unicorn, l'application ou l'interpréteur Ruby sans perdre la moindre connexion.
De même, Unicorn est optimisé pour servir des clients rapides. Il est donc très souvent utilisé derrière un reverse-proxy, qui pourra bufferiser les requêtes des clients lents.
A l'inverse, utiliser Unicorn pour des connexions longues comme du Comet (Comet désigne un ensemble de techniques où un serveur maintient des connexions HTTP ouvertes pour pouvoir pousser des contenus vers les clients) ou des websockets serait très inefficace, je vous conseille pour cela de regarder Rainbows : c'est un projet inspiré d'Unicorn qui vise justement à répondre à cette problématique particulère.
Aller plus loin
- Unicorn (103 clics)
- Annonce de la version 1.0.0 (8 clics)
- La puissance d'Unicorn chez twitter (39 clics)
- L'utilisation d'Unicorn par Github (34 clics)
- I like Unicorn because it's Unix (9 clics)
- Rainbows (23 clics)
# licorne rose
Posté par eastwind☯ . Évalué à 0.
http://shanghai.waihuo.com/fuwusheng/a245149.shtml
# éviter de réinventer la roue
Posté par __o . Évalué à 8.
Python, PHP ou Perl s'utilisent très bien via un mod_ pour apache (ou autre serveur) ou de façon plus portable / moins spécifique au serveur via CGI, FastCGI, WSGI, etc. Pourquoi pas Ruby ?
(Je ne connais pas beaucoup le monde Ruby, ce sont de vrais questions :) ).
[^] # Re: éviter de réinventer la roue
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Tout d'abord, je me rends compte que ma dépêche pourrait laisser à penser qu'Unicorn est un concurrent d'apache2 ou de nginx. Ce n'est pas le cas, il est utilisé pour du contenu dynamiques, pas pour servir des ressources statiques.
Les mod_* pour apache, ça existe aussi dans le monde Ruby : ça s'appelle phusion passenger. Il existait auparavant un mod_ruby, mais il n'est plus maintenu et personne ne l'utilisait car il avait des performances désastreuses.
Mais ces solutions ne conviennent pas à tout le monde : certains utilisent d'autres serveurs web comme nginx, d'autres vont faire tourner les applications Rails sur plusieurs serveurs et n'ont pas envie de faire tourner apache sur tous ces serveurs, etc. Ces contraintes se rencontrent généralement sur des sites à fort trafic pour lesquels on cherche à séparer les problématiques pour différentes raisons : meilleures performances, plus facile d'isoler les bugs, maintenance plus aisée, etc. Pour arriver à cela, le serveur applicatif va servir des requêtes HTTP dynamiques très rapidement.
On le place derrière un reverse-proxy pour un tas de raisons (sécurité, bufferiser les uploads, etc.) mais surtout pour éviter qu'il ne serve les fichiers statiques (nginx, ou à défaut apache, fait ça bien mieux).
Maintenant, pourquoi utiliser HTTP plutôt que CGI ou FastCGI pour communiquer entre le reverse-proxy et les processus applicatifs ? J'aurais envie de dire que HTTP est un protocole connu qui convient bien pour ça, alors pourquoi utiliser autre chose ?
Pour WSGI, il n'a pas vraiment sa place avec CGI ou fastCGI, c'est une interface pour les applications Python qui définit quelle fonction appeler (et comment) quand une requête HTTP arrive. Sous le capot, ça peut utiliser un mod_ pour apache, du CGI, du fastcgi, etc.
En bref, nous avons quasiment une équivalence un pour un entre le monde Python et le monde Ruby :
mod_python <-> mod_ruby (tous les 2 RIP)
mod_wsgi <-> phusion passenger
wsgi <-> rack
gunicorn <-> unicorn
PS : j'ai pris exemple sur Python, car en dehors de Ruby, c'est ce que je connais de mieux.
PS2 : on a un bonus quand on arrive à caser 3 liens pertinents vers des dépêches LinuxFr.org que l'on a soi-même rédigé dans les 3 derniers mois ?
[^] # Re: éviter de réinventer la roue
Posté par __o . Évalué à 3.
> d'autres vont faire tourner les applications Rails sur plusieurs serveurs et n'ont pas envie de faire tourner apache sur tous ces serveurs, etc.
FastCGI permet de faire ça, et sans la lourdeur / complexité du protocole HTTP (enfin je suppose que ces serveurs Ruby n'implémentent que HTTP/1.0, ce qui limite la complexité). FastCGI est conçu dés le départ pour la performance, c'est un protocol binaire, plus facile à parser que HTTP, et qui peut fonctionner sur des sockets unix ou tcp (donc on peut avoir un apache/nginx qui transmet les requêtes à une ferme de serveurs FastCGI).
> On le place derrière un reverse-proxy pour un tas de raisons (sécurité, bufferiser les uploads, etc.) mais surtout pour éviter qu'il ne serve les fichiers statiques (nginx, ou à défaut apache, fait ça bien mieux).
C'est bien ce que j'avais compris, ce qui m'amenait à la question "pourquoi HTTP ?"
> J'aurais envie de dire que HTTP est un protocole connu qui convient bien pour ça, alors pourquoi utiliser autre chose ?
FastCGI a été créé spécifiquement pour ça :)
[^] # Re: éviter de réinventer la roue
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Je constate juste qu'en pratique, les serveurs applicatifs qui utilisent HTTP sont en train de remplacer FastCGI et qu'ils ont l'air plus performants.
[^] # Re: éviter de réinventer la roue
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Que ce soit du fcgi, du http, du ajp13 ça n'importe pas vraiment. L'implantation de fcgi en ruby à toujours été explosive (au sens propre du terme) d'où http.
Pour php par exemple fastcgi va très bien. Pour python, il semble que wsgi soit en vogue ...
l'important est la séparation frontal / application et l'implémentation.
# A noter que
Posté par M.Poil (site web personnel) . Évalué à 1.
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
# Merci beaucoup!
Posté par djano . Évalué à 2.
Est ce que la nouvelle version de linuxfr.org utiliseras Unicorn?
[^] # Re: Merci beaucoup!
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Je ne sais pas encore. J'étais plutôt parti pour thin, mais Unicorn est intéressant aussi. Va falloir que je regarde pus en détails les deux.
[^] # Re: Merci beaucoup!
Posté par jhc_ . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.