Dans cet article nous allons expliquer et comparer les modes d’exécution CGI, FastCGI et module Apache. Nous verrons dans chacun des cas les implémentations disponibles. Cela vous permettra d’y voir plus clair et de faire le choix le plus approprié selon votre besoin 🙂
Sommaire
CGI vs Fast-CGI vs module Apache
Ces 3 méthodes vont décrire la façon dont les scripts PHP seront exécutés par le serveur.
L’utilisation de module Apache se caractérise par l’intégration de l’interpréteur PHP dans chaque process Apache. De cette manière, chaque Worker Apache pourra exécuter des scripts PHP. L’implémentation la plus courante est mod_PHP.
CGI et FastCGI sont des protocoles indépendants de PHP. Ils vont indiquer comment le serveur va exécuter un script après une requête HTTP.
En deux mots, CGI améliore la sécurité par rapport au mod_PHP car il isole l’interprétation du code PHP dans un processus distinct. Il est connu pour être très lent et c’est pourquoi il n’est quasiment plus utilisé de nos jours.
FastCGI améliore de façon importante les performances du protocole CGI (d’où son nom). Il est également moins gourmand en ressource que mod_PHP. Son implémentation la plus répandue est PHP-FPM.
Tableau comparatif
Dans ce tableau j’ai choisi les 3 implémentations les plus courantes de chaque type de handler.
Type de handler
Module Apache
CGI
FastCGI
Implémentation la plus courante
mod_PHP(aussi appelé DSO)
CGI
PHP-FPM
Avantages
Facile à installer, à configurer et à mettre à jour.
Plus de sécurité que mod_PHP.
Compatible pour de nombreux types de serveur web. Plus de sécurité que mod_PHP comme les process sont isolés du serveur web. Le propriétaire des fichiers créés par PHP peut être spécifié. Il est possible d’avoir plusieurs versions de PHP cohabitants sur le même serveur.
Inconvénients
Disponible uniquement pour Apache. mod_PHP uniquement : Les fichiers créés par PHP ont les droits du process Apache ce qui pose généralement des difficultés lors de l’édition de ces fichiers. Consommation de RAM d’Apache plus importante.
Lent pour les sites à fort trafic.
Plus difficile à configurer que mod_PHP.
Alternative
suPHP (permet une meilleur gestion des droits et une amélioration de la sécurité)
On peut entendre parler de PHP FastCGI mais il n’est plus disponible, il a été remplacé par PHP-FPM. Des modules Apaches permettent d’utiliser FastCGI comme: mod_fcgid. Il est néanmoins conseillé à l’heure actuelle d’utiliser PHP-FPM.
Tableau comparatif FastCGI vs CGI vs Module Apache
Lequel choisir ?
Comme souvent à la fin d’un comparatif la réponse est “ça dépend des cas”.
Pour un site avec peu de trafic et qui n’a pas de besoins particuliers en sécurité mod_PHP fera l’affaire. Des alternatives ont émergé pour pallier à ses faiblesses (notamment suPHP).
Malgré tout la fondation Apache a l’air de pousser vers PHP-FPM. Voici deux extraits de la documentation trouvée sur l’espace confluence de la fondation Apache, dans le guide d’installation de PHP-FPM :
“This means that we can now run secure, fast, and dependable PHP code using only the stock apache httpd and php.net releases; no more messing around with suphp or suexec – or, indeed, mod_php.’ – consulté sur https://cwiki.apache.org/confluence/display/HTTPD/PHP-FPM le 07/05/2020
ou
“Using mod_php in most cases is not a viable solution, since it introduces scalability issues with the added RAM requirement for each httpd process.”
Mon avis personnel après ces recherches est que l’implémentation PHP-FPM est en voie de devenir un standard de part ses performances sur des trafics de toute taille et son gain en matière de sécurité.
Il arrive que la code review nous empêche de merge nos PR assez vite et qu’on se retrouve à tirer une branche d’une branche de travail pour avancer 😔
Une fois la première PR squash et merge, la PR issue de la seconde branche se retrouve avec des conflits 💥
Si vous avez déjà vécu cette situation, il y a de bonnes chances que vous ayez cherry-pick vos commits de travail sur une...
Il arrive souvent que pour tester unitairement des règles de validation, on doive tester le même cas mais avec des exemples différents. Sans tests paramétrés, ça revient à faire un test par cas ce qui peut alourdir notre fichier de tests.
On va voir comme...
Avant .Net 8, tester du code qui utilise DateTime.Now() n’était pas trivial, on devait faire en sorte de mocker la Clock dans nos tests. Depuis .Net 8, c’est beaucoup plus facile grâce à TimeProvider inclut par défaut !
En deux mots, TimeProvider est une...
La gestion des erreurs de son API est très importante pour que les consommateurs puissent avoir une description claire du problème mais c’est souvent fastidieux à maintenir.
On va voir comment avoir des statuts de réponse cohérent et des messages d’erre...
