C'est un joyau qui reçoit le courrier sur localhost lors de l'envoi de courrier dans l'environnement de développement et fournit une interface WEB pour lire le courrier reçu. En d'autres termes, jusqu'à présent, "lorsque j'ai envoyé un e-mail dans l'environnement de développement, j'ai récupéré le texte qui était sorti dans le journal" peut maintenant être "visualisé par le mailer WEB".
C'est une sorte de bijou appelé serveur rack, et il y a webrick, unicon, puma, passager, falcon etc. dans la même boîte. Chaque serveur rack a ses propres caractéristiques, mais rails5 a été fourni avec puma et accumule régulièrement des enregistrements d'utilisation dans les environnements de production, de sorte que le standard de facto devient puma. Je pense.
Pour être honnête, mince semble être en baisse ces derniers temps. Alors pourquoi mailcatcher utilise-t-il thin au lieu de puma?
La raison pour laquelle j'utilise thin est d'exécuter websocket sur sinatra. (mailcatcher est conçu pour mettre à jour l'écran en temps réel lorsqu'il reçoit un e-mail en utilisant websocket sur l'interface WEB en utilisant sinatra.)
La prise Web ne fonctionne pas avec la combinaison de sinatra et de puma. La raison pour laquelle websocket fonctionne avec thin est qu'il s'agit d'un type de boucle d'événement utilisant EventMathine. https://github.com/sinatra/sinatra/issues/1035
À partir de là, mon imagination et mon impression sont que dans le cas d'un modèle de thread de travail comme puma, il n'est pas possible de sécuriser un endroit pour maintenir la connexion websocket afin de sécuriser les ressources pour chaque worker, donc la connexion websocket Même si vous mettez en place, il est rejeté lorsque vous avez terminé la demande. En revanche, dans le cas du thin, puisqu'il s'agit d'un type de boucle d'événement, j'ai pensé qu'il était possible de maintenir la connexion jusqu'à ce qu'elle soit déconnectée. Je pense que la même chose se produit avec sinatra et licorne.
Oh, n'utilisez-vous pas puma pour Rails Action Cable? puma et websocket ne fonctionnent pas, non? J'ai pensé, alors j'ai recherché. ActionCable avait un mécanisme équivalent à EventMathine qui utilisait le pubsub de Redis pour connecter le front et les backends et conserver la connexion websocket dans la couche rails.
En regardant le fait que les rails incorpore des fonctions qui supposent l'utilisation du type de thread de travail, je pense que les serveurs de type de thread de travail continueront d'être utilisés. Je pense également que GVL est impliqué dans l'arrière-plan de cette décision, et je pense qu'il est difficile d'utiliser les ressources du serveur car le serveur de type boucle d'événements est un processus unique.
fin
Recommended Posts