Pourquoi ne Licorne doivent être déployés de concert avec Nginx?
Je voudrais savoir la différence entre Nginx et la Licorne. Comme je le comprends, Nginx est un serveur web, tandis que la Licorne est un Rubis serveur HTTP.
Depuis deux Nginx et la Licorne peut traiter les requêtes HTTP, ce qui est la nécessité d'utiliser la combinaison de Nginx et la Licorne pour le RoR applications?
- Bonne question ! Je pense que le titre de cette question, "Pourquoi nous avons besoin de la combinaison de nginx et la licorne. 😉 Les réponses ont été très utiles pour moi.
- J'ai ajouté une réponse qui explique plus en détail pourquoi la Licorne a besoin d'un reverse proxy comme Nginx en face d'elle. Vous pourriez vouloir vérifier 😉
Vous devez vous connecter pour publier un commentaire.
Nginx
Licorne
Reportez-vous à licorne sur github pour plus d'informations.
Nginx est un pur serveur web qui est conçu pour servir du contenu statique et/ou de rediriger la requête vers une autre prise pour traiter la demande.
La licorne est un Rack de serveur web et uniquement destiné à accueillir un "Rack App' qui est généralement de générer du contenu dynamique. Rack applications peuvent également servir du contenu statique, mais il est moins efficace que la plupart des autres traditionnels serveurs web.
Plus RoR installations utilisent une combinaison des deux traditionnels des serveurs web et des serveurs Rack d'appliquer le meilleur de leurs capacités. Nginx est incroyablement rapide à une demande de réexpédition par l'intermédiaire de proxy d'équilibrage et de servir du contenu statique. La licorne est tout à fait capable de traiter les en-têtes HTTP et d'équilibrer les demandes entrantes à Ruby pour le traitement.
Cette réponse est complémentaire à l'autre et explique pourquoi Licorne besoins nginx en face d'elle.
TL;DR La raison que la Licorne est généralement déployé avec un reverse proxy comme nginx est parce que ses créateurs délibérément conçu de sorte, faire un compromis pour des raisons de simplicité.
Tout d'abord, il n'y a rien qui vous retient de déploiement de la Licorne sans un reverse proxy. Cependant, ce ne serait pas une très bonne idée; nous allons voir pourquoi.
Licorne suit la philosophie d'Unix qui est à faire une chose et le faire bien, et qui est de servir rapide, à faible latence, les clients (nous allons voir ce que cela signifie plus tard). Le fait que la Licorne est conçu pour rapide, à faible latence, les clients implique également que ce n'est pas très bon avec lente, à latence élevée clients, ce qui est vrai. C'est l'un de la Licorne points faibles et c'est là un proxy inverse entre en jeu: il se trouve en face de la Licorne et prend soin de ceux lent clients (nous allons voir comment plus tard).
Heureusement, tel un proxy inverse existe déjà et s'appelle nginx.
La décision de traiter rapidement les clients, simplifie grandement la conception de la Licorne et permet beaucoup plus simple et plus petit la base de code, au prix d'une complexité accrue sur le déploiement du département (ie. vous devez déployer nginx trop en plus de la Licorne).
Une alternative décision pourrait être la conception de la Licorne de telle manière qu'il n'aurait pas besoin d'un proxy inverse. Toutefois, cela signifie qu'il faudrait mettre en œuvre des fonctionnalités supplémentaires pour faire toutes les choses que maintenant nginx n', résultant en une plus complexe à base de code et plus d'efforts d'ingénierie.
Plutôt que ses créateurs ont pris la décision d'exploiter les logiciels éprouvés et très bien conçu, et pour éviter de perdre du temps et de l'énergie sur des problèmes déjà résolus par d'autres logiciels.
Mais revenons technique et de répondre à votre question:
Ici sont quelques-uns des principaux raisons:
Licorne utilise blocage I/O pour les clients
En s'appuyant sur un reverse proxy signifie que la Licorne n'a pas besoin pour utilisation non-blocage I/O. au Lieu de cela, il peut utiliser le blocage des I/O qui est intrinsèquement plus simple et plus facile pour le programmeur à suivre.
Également que la CONCEPTION précise:
Cependant, cela a aussi des conséquences:
Point clé n ° 1: la Licorne n'est pas efficace avec les clients lents
(Pour des raisons de simplicité, nous supposons que le programme d'installation avec 1 Licorne travailleur)
Puisque le blocage I/O est utilisé, une Licorne travailleur ne peut que servir un client à la fois, de sorte qu'un client lente (ie. l'un avec une connexion lente) aurait pour effet de maintenir le travailleur occupé pendant un temps plus long (un rapide client ferait). Dans l'intervalle, les autres clients juste attendre jusqu'à ce que le travailleur est à nouveau libre (ie. demandes s'accumulent dans la file d'attente).
Pour contourner ce problème, un reverse proxy est déployé devant de la Licorne, qui entièrement tampons les demandes entrantes et la demande des réponses, et l'envoie ensuite à chacun d'eux à la fois (aka cuillère-nourrit) à la Licorne et les clients, respectivement. À cet égard, on pourrait dire que le reverse proxy "boucliers" Licorne de ralentir les clients du réseau.
Heureusement Nginx est un candidat idéal pour ce rôle, car il est conçu pour gérer des milliers de centaines de clients simultanés efficacement.
Il est d'une importance cruciale que le proxy inverse doit être dans le même réseau local comme la Licorne (généralement dans la même machine physique communiquer w/Licorne via une socket de domaine Unix), de sorte que la latence du réseau est maintenu à un minimum.
Donc, un tel proxy efficacement joue le rôle d'un à la clientèle rapide que la Licorne est conçu pour servir en premier lieu, car il demandes de proxy de la Licorne rapide et maintient les travailleurs occupés pour le peu de temps (par rapport à combien de temps un client avec une connexion lente ferait).
Point-clé n ° 2: la Licorne ne prend pas en charge le protocole HTTP/1.1 keep-alive
Depuis Licorne utilise blocage I/O, cela signifie aussi qu'il ne peut pas soutenir le HTTP/1.1 keep-alive fonctionnalité, puisque les connexions persistantes de la lenteur des clients rapidement occuper l'ensemble de l'Licorne travailleurs.
Donc de miser sur HTTP keep-alive, devinez quoi: un reverse proxy est utilisé.
nginx sur l'autre main, peut gérer des milliers de connexions simultanées à l'aide de seulement un petit nombre de threads. Par conséquent, il n'a pas les limites de simultanéité un serveur comme Licorne a (qui, pour l'essentiel, limitée au montant de processus de travail), ce qui signifie qu'il peut gérer les connexions persistantes à l'amende juste. Plus de la manière dont cela fonctionne peut être trouvé ici.
C'est pourquoi nginx accepte les connexions persistantes de la part des clients et des procurations à la Licorne-dessus de la plaine via des connexions généralement une socket Unix.
Point #3: la Licorne n'est pas très bon à servir les fichiers statiques
Encore une fois, de servir les fichiers statiques est une chose que de la Licorne peut faire, mais n'est pas conçu pour faire efficacement.
A l'inverse, les proxys inverses comme nginx, mais sont beaucoup plus mieux (c'est à dire.
sendfile(2)& de la mise en cache).Plus
Il y a d'autres points qui sont décrites dans les La PHILOSOPHIE document (voir "Amélioration de la Performance Par le biais de Proxy Inverse").
Voir aussi certains de nginx est des fonctionnalités de base.
Nous voir en capitalisant sur des logiciels existants (ie. nginx) et en suivant la philosophie d'Unix de "faire une chose et le faire bien", la Licorne est en mesure de suivre une simplification de la conception et de la mise en œuvre, tout en maintenant pour être efficace à servir Rack applications (par exemple. votre application Rails).
Pour plus d'informations, reportez-vous à la Licorne la philosophie et conception documents qui expliquent plus en détail les choix derrière Licorne conception et pourquoi nginx est considéré comme un bon proxy inverse pour la Licorne.
Nginx peut être utilisé pour servir les clients lents sur une licorne serveur en tant que clients lents étouffe la licorne serveur. Nginx est utilisé comme une sorte de proxy de mise en mémoire tampon toutes les demandes et les réponses à ralentir les clients.
Voir http://unicorn.bogomips.org/