Je voudrais connaître la différence entre Nginx et Unicorn. D'après ce que j'ai compris, Nginx est un serveur web tandis que Unicorn est un serveur HTTP Ruby.
Puisque Nginx et Unicorn peuvent tous deux traiter les requêtes HTTP, quel est le besoin d'utiliser la combinaison de Nginx et Unicorn pour les applications de RoR ?
Nginx est un pur serveur web destiné à servir du contenu statique et/ou à rediriger la demande vers un autre socket pour traiter la demande.
Unicorn est un serveur web Rack et n'est destiné qu'à héberger une "Rack App" qui génère généralement du contenu dynamique. Les applications Rack peuvent également servir du contenu statique, mais elles sont moins efficaces que la plupart des autres serveurs web traditionnels.
La plupart des configurations de RoR utilisent une combinaison de serveurs web traditionnels et de serveurs Rack afin d'appliquer le meilleur de leurs capacités respectives. Nginx est incroyablement rapide pour la redirection des requêtes via l'équilibrage du proxy et la mise à disposition de contenu statique. Unicorn est tout à fait capable de traiter les en-têtes HTTP et d'équilibrer les demandes entrantes vers Ruby pour traitement.
Cette réponse est complémentaire aux autres et explique pourquoi Unicorn a besoin de nginx en face d'elle .
TL;DR Si Unicorn est généralement déployé avec un proxy inverse comme nginx, c'est parce que ses créateurs l'ont délibérément conçu ainsi, en faisant un compromis pour la simplicité.
Tout d'abord, il n'y a rien qui vous empêche de déployer Unicorn sans un proxy inverse. Cependant, ce ne serait pas une très bonne idée ; voyons pourquoi.
Unicorn suit la philosophie d'Unix qui est de faire une chose et la faire bien et qui consiste à servir clients rapides et à faible latence (nous verrons plus tard ce que cela signifie). Le fait que la licorne soit conçue pour clients rapides et à faible latence implique également qu'il n'est pas très bon avec clients lents et à forte latence ce qui est en effet vrai. C'est l'un des points faibles de Unicorn et c'est là qu'un proxy inverse entre en jeu : il se place devant Unicorn et s'occupe de ces clients lents (nous verrons comment plus tard).
Heureusement, un tel proxy inverse existe déjà et s'appelle nginx .
La décision de ne gérer que les clients rapides simplifie grandement la conception d'Unicorn et permet d'obtenir une base de code beaucoup plus simple et plus petite, au prix d'une certaine complexité supplémentaire pour le service de déploiement (par exemple, vous devez également déployer nginx en plus d'Unicorn).
Une autre solution consisterait à concevoir la Licorne de manière à ce qu'elle n'ait pas besoin d'un proxy inverse. Cependant, cela signifie qu'il faudrait implémenter une fonctionnalité supplémentaire pour faire toutes les choses que fait actuellement nginx, ce qui entraînerait un code plus complexe et des efforts d'ingénierie supplémentaires.
Au lieu de cela, ses créateurs ont pris la décision de s'appuyer sur des logiciels existants, éprouvés et très bien conçus, et d'éviter de perdre du temps et de l'énergie sur des problèmes déjà résolus par d'autres logiciels.
Mais entrons dans le vif du sujet et répondons à votre question :
Pourquoi Unicorn doit-il être déployé avec nginx ?
Voici quelques-unes des principales raisons :
S'appuyer sur un proxy inverse signifie que Unicorn ne peut pas besoin de pour utiliser des E/S non bloquantes. Au lieu de cela, il peut utiliser des E/S bloquantes, ce qui est intrinsèquement plus simple et plus facile à suivre pour le programmeur.
De même que le DESIGN Le document indique :
[L'utilisation d'E/S bloquantes] permet de suivre un chemin de code plus simple dans l'interpréteur Ruby et de réduire le nombre d'appels système.
Toutefois, cela a aussi des conséquences :
(Pour des raisons de simplicité, nous supposons une configuration avec un travailleur Licorne).
Puisque le blocage des E/S est utilisé, un travailleur Unicorn ne peut servir qu'un seul client à la fois Ainsi, un client lent (c'est-à-dire un client avec une connexion lente) maintiendrait effectivement l'ouvrier occupé plus longtemps (qu'un client rapide ne le ferait). Pendant ce temps, les autres clients attendent que le travailleur soit à nouveau libre (c'est-à-dire que les demandes s'accumulent dans la file d'attente).
Pour contourner ce problème, un reverse proxy est déployé devant Unicorn, qui tampons complets demandes entrantes et les réponses de l'application, puis envoie chacune d'entre elles en même temps (c'est-à-dire qu'il les nourrit à la cuillère) à la Licorne et aux clients, respectivement. À cet égard, on peut dire que le proxy inverse "protège" Unicorn des clients lents du réseau.
Heureusement, Nginx est un excellent candidat pour ce rôle, car il est conçu pour gérer efficacement des milliers de centaines de clients simultanés.
Il est essentiel que le proxy inverse se trouve dans le même réseau local qu'Unicorn (généralement dans la même machine physique communiquant avec Unicorn via un socket de domaine Unix), afin que la latence du réseau soit réduite au minimum.
Ainsi, un tel proxy joue effectivement le rôle d'un client rapide que Unicorn a été conçu pour servir en premier lieu, puisqu'il transmet les demandes à Unicorn par proxy. rapide et garde les travailleurs occupés pour la durée la plus courte possible (par rapport au temps que prendrait un client avec une connexion lente).
Puisque Unicorn utilise des E/S bloquantes, cela signifie également qu'il ne peut pas prendre en charge la fonction keep-alive HTTP/1.1, car les connexions persistantes des clients lents occuperaient rapidement tous les travailleurs Unicorn disponibles.
Par conséquent, pour tirer parti de l'option HTTP keep-alive, devinez quoi : un proxy inverse est utilisé.
En revanche, nginx peut gérer des milliers de connexions simultanées en utilisant seulement quelques threads. Par conséquent, il n'a pas les limites de concurrence d'un serveur comme Unicorn (qui est essentiellement limité au nombre de processus de travail), ce qui signifie qu'il peut très bien gérer les connexions persistantes. Pour en savoir plus sur le fonctionnement de ce système, consultez ici .
C'est pourquoi nginx accepte les connexions "keep-alive" des clients et les transmet à Unicorn par le biais de connexions simples, généralement via un socket Unix.
Encore une fois, servir des fichiers statiques est une chose que Unicorn peut mais n'est pas conçu pour le faire efficacement.
D'un autre côté, les proxies inversés comme nginx sont bien plus performants (c'est-à-dire qu'ils sont plus efficaces). sendfile(2) et la mise en cache).
Il y a d'autres points qui sont soulignés dans le PHILOSOPHIE (voir "Amélioration des performances grâce au proxy inverse" ).
Voir également certains des Les caractéristiques de base de nginx .
Nous constatons qu'en exploitant les logiciels existants (par exemple nginx) et en suivant la philosophie Unix "faire une chose et la faire bien", Unicorn est capable de suivre une conception et une mise en œuvre plus simples tout en continuant à servir efficacement les applications Rack (par exemple votre application Rails).
Pour plus d'informations, consultez le site de Unicorn philosophie et design qui expliquent plus en détail les choix qui sous-tendent la conception de Unicorn et pourquoi nginx est considéré comme un bon proxy inverse pour Unicorn.
Nginx
Licorne
Se référer à la licorne sur github pour plus d'informations.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
