J'essaie d'énoncer les réponses ci-dessus de manière plus précise (et de corriger certaines parties)...
le multiplexage permet de réduire la charge de travail liée à la création de nouvelles connexions avec les clients FCGI en imbriquant efficacement les morceaux de demandes
Contrairement au keep-alive, il réduit considérablement les nouvelles connexions, en particulier sur les serveurs à forte charge ou en cas d'utilisation de micro-services (beaucoup de micro-requêtes). En outre, il est presque nécessaire dans le cas d'un équilibrage à travers le réseau (on ne peut donc plus utiliser les sockets unix et le processus d'établissement des connexions devient de plus en plus prioritaire).
et en même temps d'activer le modèle "keep-alive" pour la connexion
Bien que le multiplexage ne soit pas nécessaire pour le keep-alive, le keep-alive est presque nécessaire pour le multiplexage (sinon cela n'aurait pas de sens).
J'ai constaté qu'il n'y a pas de serveur qui mette en œuvre le multiplexage FCGI.
Il existe peu de serveurs qui prennent en charge le multiplexage dès le départ, mais...
J'ai déjà vu plusieurs modules d'autres développeurs et j'ai mon propre module fcgi pour nginx (en remplacement) qui supporte les requêtes multiplex FastCGI. Il peut montrer l'augmentation réelle des performances dans la pratique, en particulier si les flux en amont sont connectés sur le réseau. Si quelqu'un en a besoin, j'essaierai de trouver le temps de le rendre disponible sur github, etc.
[ de la réponse ci-dessus ] Le multiplexage FastCGI est généralement une mauvaise idée, car FastCGI ne prend pas en charge le contrôle de flux. Cela signifie que : Si un backend FastCGI envoie des données, mais que le client http ne peut pas les recevoir assez rapidement, le serveur web doit sauvegarder toutes ces données, jusqu'à ce qu'elles puissent être envoyées au client.
Ce n'est pas le cas. Normalement, les gestionnaires FastCGI sont entièrement asynchrones, le pool de travailleurs est séparé des travailleurs chargés de la livraison, etc. Ainsi, chaque morceau reçoit un identifiant de requête, de sorte que si deux ou plusieurs travailleurs en amont écrivent simultanément sur une seule connexion, les morceaux que nginx obtiendra seront simplement plus petits. C'est ce que l'on appelle le contre unique. En ce qui concerne la question "le serveur web doit sauvegarder toutes ces données", il le fait dans tous les cas (que le multiplexage soit utilisé ou non), car sinon on peut se retrouver dans une situation de mémoire saturée s'il y a trop de données en attente disponibles pour la réponse. Ainsi, soit le backend doit produire moins de données (ou être contrecarré), soit le serveur web doit les recevoir dès que possible et les transmettre au client ou les sauvegarder dans un stockage intermédiaire (et par exemple, nginx le fait si la taille des données en attente dépasse les valeurs configurées avec taille_du_tampon_de_cgi y fastcgi_buffers ).
[ de la réponse ci-dessus Lors de l'utilisation du multiplexage, le serveur web doit lire toutes les données du backend fastcgi, même si l'un des clients ne reçoit pas les données assez rapidement.
C'est également faux. Le serveur web ne doit lire qu'un seul morceau de réponse jusqu'à la fin, et les bons groupes de travail ont une gestion "intelligente" qui envoie automatiquement les morceaux au serveur web dès que possible (c'est-à-dire s'ils sont disponibles). Ainsi, si plusieurs fournisseurs de contenu écrivent sur des canaux dits "réfléchis" de la même connexion réelle, les paquets en attente seront séparés et les morceaux seront reçus de nginx dès que les données de réponse seront disponibles. Ainsi, seul le débit de la connexion est déterminant, et la vitesse à laquelle les clients recevront les données n'a aucune importance. Une fois encore, le multiplexage permet d'économiser considérablement le temps nécessaire à l'établissement de la connexion, ce qui réduit le nombre de demandes en attente ainsi que le temps d'exécution de la demande commune (taux de transaction).
