Calculer Girl
  1. Calculer Girl
  3. Comment FastCGI fonctionne-t-il sur un serveur Web (par exemple, Apache 2.2+)?
Intereting Posts
Comment puis-je exécuter des scripts Perl en utilisant FastCGI sur Nginx? Obtenir le nom du fichier copié dans le presse-papiers à partir d’une pièce jointe à un courrier électronique dans VB.NET Déplacement du site Web ASP.NET MVC vers un serveur Attendez l’entrée pendant un certain temps si une fonction retournée dans le processus enfant peut être capturée dans le processus parent déplacer le jeu de fichiers dans unix Erreur Django: 400 avec Debug = False et ALLOWED_HOSTS = Problème de fragmentation du cache APC Erreur d’installation du compositeur – la sortie n’est pas un tty, l’entrée n’est pas un tty La journalisation de Django ne fonctionne pas dans Apache. Comment compter les lignes dans un document? Comment désactiver (ou au moins remplacer) la coloration syntaxique dans nano via ~ / .nanorc? Consigner un en-tête HTTP dans les journaux d’access Apache2 Le programme ne peut pas démarrer car libgcc_s_dw2-1.dll est manquant NGINX Config: projet Symfony dans le sous-chemin

Comment FastCGI fonctionne-t-il sur un serveur Web (par exemple, Apache 2.2+)?

J’ai jeté un coup d’oeil aux sources de FastCGI (fcgi-2.4.0) et en fait il n’y a aucun signe de fork. Si je me trompe, le serveur Web propose un processus pour le module FastCGI (compilé ou chargé en tant que SO / DLL) et gère le contrôle du socket principal (le port TCP: 80 généralement).

Sur * nix, le module FastCGI “verrouille” ce socket en utilisant un verrou en écriture de fichier (libfcgi / os_unix.c: 989) sur tout le descripteur de fichier (le socket en effet); De cette façon, lorsque de nouvelles connexions génèrent des revenus, seul le module FastCGI peut les traiter. Le verrou de socket entrant est libéré juste avant de passer au traitement HTTP req.

Comme le module FastCGI n’est pas multi-processus / thread (pas d’utilisation interne de fork / pthread_create), je suppose que le traitement simultané de plusieurs connexions simultanées est obtenu via le serveur Web (via OS_SpawnChild) de n processus FastCGI. Si nous générons, par exemple, 3 processus FastCGI (Apache appelle 3 x OS_SpawnChild), cela signifie-t-il que seules 3 requêtes peuvent être servies simultanément?

A) Ma vision de FastCGI est-elle correcte?

B) Si le coût pour le système d’exploitation de générer un nouveau processus / créer une connexion à la firebase database locale peut être considéré comme négligeable, quels sont les avantages de FastCGI par rapport à une approche exécutable à l’ ancienne ?

Merci Ema! 🙂

Le gain de vitesse de FastCGI par rapport à un CGI normal est que les processus sont persistants. Par exemple, si vous avez des descripteurs de firebase database à ouvrir, vous pouvez les faire une fois. Identique pour toute mise en cache.

Le principal avantage vient de ne pas avoir à créer de nouveau php / perl / etc. interprète à chaque fois, ce qui prend une quantité de temps surprenante.

Si vous souhaitez gérer plusieurs connexions simultanées, vous devez exécuter plusieurs processus FastCGI Processus. FastCGI n’est pas un moyen de gérer plus de connexions via n’importe quel type d’access concurrentiel. C’est un moyen d’accélérer les requêtes individuelles, ce qui permettra de traiter davantage de demandes. Mais oui, vous avez raison, plus de demandes simultanées nécessitent plus de processus en cours d’exécution.

Les processus générés par FastCGI sont persistants, ils ne sont pas supprimés une fois la requête gérée, ils sont plutôt “regroupés”.

B, oui, si le coût de la reproduction est nul, la version CGI héritée serait plutôt bonne. Donc, si vous n’avez pas beaucoup de résultats, les anciennes versions de CGI vont bien. Le but de cgi rapide est de faire des choses qui bénéficient de beaucoup de stockage persistant, ou des structures à construire AVANT de pouvoir faire votre travail, comme exécuter des requêtes sur des bases de données volumineuses. d’avoir à recharger le shebang à chaque fois que vous voulez exécuter une requête.

C’est important quand vous avez beaucoup de coups.

Effectivement,

donc comme vu (A) est ok, maintenant qu’en est-il (B)? Si je parle d’exécutables (programmes C / C ++ correctement compilés, pas de scripts tels que perl / php / …), et si nous considérons le coût du processus et le coût de la nouvelle connexion de la firebase database négligeables, cette approche (FastCGI) est juste une sorte de petit gain par rapport aux exécutables CGI simples?

Je veux dire, étant donné que Linux est très rapide pour générer un processus et que la firebase database fonctionne localement (par exemple, le même hôte MySQL), le temps nécessaire pour démarrer un nouvel exécutable et se connecter à la firebase database est pratiquement nul. Dans ce cas, sans rien à interpréter, seuls les modules Apache C / C ++ seraient plus rapides que cela.

En utilisant l’approche FastCGI, vous êtes encore plus vulnérable aux memory leaks, vu que le processus n’est pas lancé / redémarré à chaque fois … A ce stade, si vous devez développer votre CGI en C / C ++, il ne serait pas préférable de utiliser directement les anciens modules CGI et / ou Apache C / C ++?

Encore une fois, je ne parle pas de scripts (perl / php / …), je parle de CGI compilé.

Merci encore, Cheers, Ema! 🙂