Pourquoi faut-il déployer Unicorn avec Nginx?
J'aimerais connaître la différence entre Nginx et Unicorn. Autant que je sache, Nginx est un serveur Web, tandis que Unicorn est un serveur HTTP Ruby HTTP.
Etant donné que Nginx et Unicorn peuvent gérer les demandes HTTP, quelle est la nécessité d'utiliser la combinaison de Nginx et Unicorn pour les applications RoR?
Nginx 
Licorne 
Reportez-vous à nicorn on github pour plus d'informations.
Nginx est un serveur Web pur conçu pour servir du contenu statique et/ou rediriger la demande vers un autre socket afin de gérer la demande.
Unicorn est un serveur Web Rack destiné uniquement à héberger une "application Rack" générant généralement un contenu dynamique. Les applications en rack peuvent également diffuser du contenu statique, mais son efficacité est inférieure à celle de la plupart des autres serveurs Web traditionnels.
La plupart des configurations RoR utilisent une combinaison de serveurs Web traditionnels et de serveurs rack pour appliquer le meilleur de leurs deux fonctionnalités. Nginx est incroyablement rapide lors de la redirection de demande via l'équilibrage du proxy et la diffusion de contenu statique. Unicorn est tout à fait capable de traiter les en-têtes HTTP et d’équilibrer les demandes entrantes avec Ruby).
Cette réponse est complémentaire aux autres et explique pourquoi Unicorn a besoin de nginx devant elle .
TL; DR Si Unicorn est généralement déployé avec un proxy inverse tel que nginx, c’est parce que ses créateurs l’ont délibérément conçu de manière à ce qu’il soit conçu de manière à simplifier les choses.
Tout d’abord, rien ne 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 Unix qui est de fait une chose et le fait bien , et c’est à servir clients rapides à faible latence (nous verrons ce que cela signifie plus tard). Le fait que Unicorn soit conçu pour clients rapides à faible latence implique également que ce n'est pas très bien avec clients lents à latence élevée , ce qui est bien vrai. C’est l’un des points faibles de Unicorn et c’est là qu’un proxy inverse entre en jeu: il est assis devant Unicorn et s’occupe de ceux-ci 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 des clients rapides simplifie grandement la conception de Unicorn et permet une base de code beaucoup plus simple et plus petite, au prix d’une complexité accrue pour le service de déploiement (c’est-à-dire que vous devez déployer nginx en plus de Unicorn).
Une autre décision pourrait consister à concevoir Unicorn de telle sorte qu’elle n’ait pas besoin de procuration inverse. Cependant, cela signifie qu'il devrait implémenter des fonctionnalités supplémentaires pour faire tout ce que fait maintenant nginx, ce qui se traduirait par une base de code plus complexe et des efforts d'ingénierie plus poussés.
Au lieu de cela, ses créateurs ont pris la décision d'exploiter les logiciels existants testés au combat 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 passons à la technique et répondons à votre question:
Pourquoi faut-il déployer Unicorn avec nginx?
Voici certaines des raisons principales:
Unicorn utilise le blocage des E/S pour les clients
S'appuyant sur un proxy inverse signifie que Unicorn ne need == utiliser des E/S non bloquantes. Au lieu de cela, il peut utiliser des E/S de blocage, ce qui est intrinsèquement plus simple et plus facile à suivre pour le programmeur.
Le document [~ # ~] [[# # ~]] indique également:
[Utiliser les E/S bloquantes] permet de suivre un chemin de code plus simple dans l’interpréteur Ruby et moins d'appels système).
Cependant, cela a aussi des conséquences:
Point clé n ° 1: Licorne n'est pas efficace avec les clients lents
(Par souci de simplicité, nous supposons une configuration avec 1 travailleur Unicorn)
Puisque le blocage des E/S est utilisé, , un travailleur Unicorn ne peut servir qu’un seul client à la fois , de sorte qu’un client lent (c’est-à-dire avec une connexion lente) garderait effectivement le travailleur occupé pendant plus longtemps (qu’un client rapide ne le ferait). Entre-temps, les autres clients attendraient simplement que le poste de travail soit à nouveau libre (les demandes s’empileraient dans la file d’attente).
Pour contourner ce problème, un proxy inverse est déployé devant Unicorn, celui-ci tampons complets demandes entrantes et les réponses de l'application, et envoie ensuite chacun d'eux à la fois (alias spoon-les alimente) à Unicorn et aux clients, respectivement. À cet égard, vous pouvez dire que le proxy inverse "protège" la Licorne des clients réseau lents.
Heureusement, Nginx est un excellent candidat pour ce rôle, car il est conçu pour gérer efficacement des centaines de centaines de clients simultanés.
Il est primordial que le proxy inverse se trouve sur le même réseau local que Unicorn (généralement sur la même machine physique communiquant avec Unicorn via une socket de domaine Unix), afin de minimiser la latence du réseau.
Ainsi, un tel proxy joue effectivement le rôle d'un fast client que Unicorn est conçu pour servir en premier lieu, car il transmet les requêtes à Unicorn fast et garde les travailleurs occupés pendant le moins de temps possible (par rapport au temps qu'un client disposant d'une connexion lente ferait).
Point clé n ° 2: Unicorn ne prend pas en charge HTTP/1.1 Keep-Alive
Comme Unicorn utilise des E/S bloquantes, cela signifie également qu’elle ne peut pas prendre en charge la fonctionnalité de maintien en activité HTTP/1.1, car les connexions persistantes des clients lents occuperaient rapidement tous les travailleurs Unicorn disponibles.
Par conséquent, pour tirer parti de la persistance de HTTP, devinez quoi: un proxy inverse est utilisé.
d'autre part, 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 simultanéité d’un serveur comme Unicorn (qui est essentiellement limité au nombre de processus de travail), ce qui signifie qu’il peut gérer des connexions persistantes sans problème. On peut trouver plus de détails sur la façon dont cela fonctionne réellement ici .
C'est pourquoi nginx accepte les connexions persistantes des clients et les envoie à Unicorn via des connexions en clair via une socket Unix.
Point n ° 3: La Licorne n'est pas très bonne pour servir des fichiers statiques
Encore une fois, servir des fichiers statiques est une chose que Unicorn peut faire mais n'est pas conçu pour faire efficacement.
D'un autre côté, les proxys inverses comme nginx sont bien meilleurs (ie. sendfile(2) & caching).
Plus
Il y a d'autres points qui sont décrits dans le PHILOSOPHIE (voir "Amélioration des performances grâce au proxy direct" ) .
Voir aussi certaines des caractéristiques de base de nginx .
Nous constatons qu'en exploitant les logiciels existants (c.-à-d. Nginx) et en suivant la philosophie Unix consistant à "faire une chose et bien le faire", Unicorn est capable de suivre une conception et une mise en œuvre simplifiées, tout en maintenant une gestion efficace des applications Rack (par exemple. votre Rails).
Pour plus d'informations, reportez-vous aux documents philosophie et conception de Unicorn, qui expliquent plus en détail les choix sous-jacents à la conception de Unicorn et expliquent pourquoi nginx est considéré comme un bon substitut pour Unicorn.
Nginx peut être utilisé pour servir des clients lents sur un serveur Unicorn, car des clients lents étrangleraient le serveur Unicorn. Nginx est utilisé comme une sorte de proxy mettant en mémoire tampon toutes les demandes et réponses des clients lents.