Thin vs Licorne sur Heroku

Question

Voulais juste avoir l'opinion des gens sur l'aide de la Licorne vs Mince comme un serveur rails. La plupart des articles/critères de référence que j'ai trouvé en ligne semble très incomplète, de sorte qu'il serait agréable d'avoir un endroit centralisé pour en discuter.

Unicron est un multi-processus serveur, bien que mince, c'est un événement et non le blocage du serveur. Basé sur des événements les serveurs sont super... si votre code est asynchrone/non bloquant - vanille rails est bloquant. Donc, sauf si vous utilisez le non-blocage des rails bibliothèques, je ne vois vraiment pas l'avantage de l'utilisation Mince. Pire encore, dans un non-blocage du serveur, si votre boucle d'e/s est le blocage que vous allez à bloquer la totalité de la boucle et de ne pas être en mesure de traiter plus de demandes jusqu'à ce que le blocage d'appel renvoie. Le blocage des bibliothèques vont ralentir mince vers le bas!

Pourquoi Heroku choisir Mince que leur serveur par défaut (pour le cèdre)? Ils sont intelligents, les gars, je suis sûr qu'ils avaient une raison.

Soufflet est un lien qui propose de remplacer Mince avec 4 Licorne travailleurs - cela fait beaucoup de sens pour moi. 4 Unicron travailleurs sur Heroku

Answer 1

Mince, c'est facile à configurer - pas optimal, mais il fonctionne, tout simplement dans le Heroku de l'environnement.

La licorne peut être plus efficace, mais il doit être configuré: Combien de travailleurs? La Précharge De L'App? Que faites-vous choisir?

J'ai publié Licorne Heroku apps avec les travailleurs à 3, 5 et 8 - basé sur la façon dont grand chaque application - combien de code, la quantité de mémoire utilisée et la quantité de trafic que vous obtenez tous aller dans la cueillette de ce numéro, et vous avez besoin de surveiller plus de temps pour vous assurer que vous avez le droit de nombre, et que votre application n'est pas en cours d'exécution hors de la mémoire.

Précharger les faux - ce qui va rendre votre application plus lent démarrage, mais quand Licorne redémarre un travailleur, c'est plus "safe" avec les connexions réseau (memcache, postgres, mongo etc)

Précharge vrai - c'est mieux, mais vous avez besoin pour gérer le serveur re-connexions correctement dans le pré-et post-fourchette de code.

Mince a aucune de ces questions hors de la boîte, mais vous obtenez seulement des processus de l'exécution.

Résumé: Il est vraiment difficile de configurer la Licorne de la zone de travail (ou à tous) pour tout le monde, alors que Mince peut juste travail pour amener les gens en cours d'exécution avec de moins en moins de demandes de soutien.

Answer 2

Récemment (il y a quelques mois) les gens derrière Phusion Passenger ajouter le support pour Heroku. Certainement c'est une alternative que vous devriez essayer et voir si répond à vos besoins.

Est très rapide, même avec 1 dyno et de la baisse du temps de réponse est palpable. Un simple Passager Ruby Heroku Démo est hébergé sur github.

Les principaux avantages que les Passagers sur Heroku revendications sont les suivantes:

• Statique de l'actif de l'accélération par le biais de Nginx - Ne laissez pas votre application Ruby servir statique actifs, laissez Nginx faire pour vous et décharger votre application pour la très importante des tâches. Nginx va faire un bien meilleur travail.

• Plusieurs processus de travail - au Lieu de courir seulement un travailleur sur un dyno, Phusion Passenger exécute plusieurs travailleurs sur une seule puissance, ce qui permet d'utiliser ses ressources à son maximum et de vous donner plus de coup pour le mâle. Cette approche est similaire à la Licorne. Mais à la différence de la Licorne, Phusion Passenger adapte de manière dynamique le nombre de processus de travail basées sur l'état actuel de la circulation, libérant ainsi des ressources lorsqu'elles ne sont pas nécessaires.

• Des optimisations de mémoire - Phusion Passenger utilise moins de mémoire que les Minces et la Licorne. Il prend également en charge la copie sur écriture de la mémoire virtuelle en combinaison avec le code de préchargement, rendant ainsi votre app, encore moins de mémoire lors de l'exécution sur Ruby 2.0.

• Requête/réponse tampon - inclus Nginx tampons demandes et les réponses, ainsi que de protéger votre application contre lentes des clients (p. ex. des appareils mobiles sur les réseaux mobiles) et l'amélioration de la performance.

• Out-of-band de collecte des ordures - Ruby garbage collector est lent, mais pourquoi s'embêter à vos visiteurs avec de longs temps de réponse? Résoudre ce problème en exécutant la collecte des ordures à l'extérieur de la normale du cycle de requête-réponse! Ce concept, introduit d'abord par la Licorne, a été amélioré: Phusion Passenger assure qu'une seule demande dans le même temps est en cours d'exécution out-of-band de collecte des ordures, ce qui élimine tous les problèmes de la Licorne-bande de garbage collection.

• JRuby soutien - Licorne est un meilleur choix que Mince, mais il ne prend pas en charge JRuby. Phusion Passenger ne.

Espérons que cette aide.

Answer 3

Heroku ne pas utiliser de routage intelligent - il, de façon aléatoire, affecter des tâches à des dynamomètres, peu importe si le dyno est occupé. Ainsi, si votre dyno ne peut pas gérer plusieurs tâches à la fois, vous aurez le temps de latence (peut-être massive de latence), même si vous payez beaucoup d'autres dynamomètres, gratuits. "C'est le droit - si votre application a besoin de 80 dynamomètres avec un routeur intelligent, il a besoin de 4 000 avec un hasard routeur. " http://news.rapgenius.com/James-somers-herokus-ugly-secret-lyrics

Heroku dit qu'ils travaillent sur ce sujet, et leur projet est de faciliter l'utilisation de la Licorne. Ils ont essentiellement dit "Oups, nous n'avons pas remarqué que c'était un problème pour quelques années... et maintenant que nous attendons, c'est certainement un problème pour Mince... donc je suppose que vous devez utiliser un autre programme que celui que nous avons été de pousser tout ce temps." http://news.rapgenius.com/Jesper-joergensen-routing-performance-update-lyrics

De la officiel Heroku explication (deuxième lien ci-dessus): "Les Rails de, en fait, n'a pas encore de façon fiable à l'appui simultané de traitement de la demande. Cela laisse Rails les développeurs incapables de tirer parti de la supplémentaires de la simultanéité des capacités offertes par le Cèdre de la pile, sauf si ils se déplacent à une concurrente serveur web de type Puma ou Licorne.

Rails applications déployées à Cedar avec Mince peut assez rapidement se retrouver avec la demande de problèmes de files d'attente. Parce que le Cèdre routeur ne s'occupe plus de files d'attente sur le nom de l'application, les demandes en attente au dyno doit attendre jusqu'à ce que les Rails simples processus travaille son chemin à travers la file d'attente. De nombreux clients ont rencontré ce problème et nous avons échoué à prendre des mesures et de leur fournir une meilleure approche pour le déploiement d'applications Rails sur le Cèdre."

Également d'intérêt est que leurs outils de performance, y compris les Nouvelles de la Relique, n'ont pas été des rapports de temps passé sur le dyno file d'attente. http://news.rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics

Oups.