Nicolas Martinez

Malheureusement, je ne comprends pas l’intérêt de bencher des configurations par défaut.

Il me semble que le plus important est de bien comprendre l’architecture logicielle inhérante à chaque server web ou MPM.

1 – MPM prefork

Le processus père crée une socket d’écoute qu’il bind sur le port 80 du serveur par défaut.
Il entre ensuite dans une boucle infinie en attente de requêtes entrantes.
Pour chaque requête entrante, il fork un nouveau process qui va être chargé de traiter la requête et de la renvoyer au client.
L’appel système fork() est un appel système extrêmement couteux en ressources car nécessitant des bacules en mode noyau, une copie du processus père intégrale en mémoire, etc …
L’avantage du prefork est de fournir une isolation maximale au niveau du traitement des requêtes et peut même permettre certaines choses très interessantes au niveau du controle des process via ITK ou SUEXEC. Couplé à des control groups kernel ce contrôle peut même devenir extrêmement pointu en dédiant par exemple un certain coeur CPU pour un certain type de requêtes, maximisant ainsi les cache hits CPU etc …
Pour moi le gros inconvéniant de ce type d’architecture est l’utilisation excessive de mémoire, de ce fait on ne tire pas bien parti des ressources hardware de la machine.
Dans la configuration par défaut que tu as testé, avec un StartServers aussi bas et un « MaxConnectionsPerChild 0 », on doit fork() un nouveau process par requête, entrainant ainsi une perte énorme de performances.
Tu devrais refaire le test avec un StartServers plus élevé afin que les appels systèmes fork() soient fait au démarrage du serveur et non à la volée, et ensuite les réutiliser pour traiter plusieurs requêtes consécutives en augmentant MaxConnectionsPerChild.

2 – MPM worker

Le processus père crée une socket d’écoute qu’il bind sur le port 80 du serveur par défaut.
Il entre ensuite dans une boucle infinie en attente de requêtes entrantes.
Pour chaque requête entrante, il crée un nouveau thread qui va être chargé de traiter la requête et de la renvoyer au client.
La création d’un thread est une opération beaucoup moins couteuse pour le système, et l’utilisation mémoire est mieux optimisée car tous les threads partagent l’espace mémoire du processus père.
Il faut quand même retenir que l’espace mémoire alloué à un process est limité … par exemple 4go sur un système 32bits. En 64 bits, cette limitation est beaucoup plus élevée mais elle existe aussi. De plus sous linux les threads étants gérés en mode noyaux, de nombreuses bascules en mode noyau et context switches sont a prévoir. Linux à du mal au dela de 300 threads par process.
C’est pour ces raisons que en mode worker, apache fork quand même plusieurs process qui servent de conteneurs de threads.
L’avantage de ce mode est donc une utilisation moinde des ressources, au prix d’une isolation moinde des requêtes. En effet, si 1 requête corromp l’espace mémoire commun, alors tu auras ThreadsPerChild 25 requêtes qui vont planter en même temps.
De plus, il faut se rappeler que le vrai parallélisme n’existe pas et qu’on reste limité par le nombre de processeurs malgré un grand nombre de threads.

3 – MPM Event // Nginx

Le principe de ce type d’architecture est de n’avoir qu’un seul process qui crée une socket d’écoute qu’il bind sur le port 80 du serveur par défaut.
Ensuite il entre dans une boucle et poll ( via select, epoll, etc … ) la socket à intervalle régulier. Chaque requête génère alors un évènement ( event ), qui est mis en attente et traité lorsque aucune lecture / écriture n’a lieu sur la socket.
Ce type de fonctionnement est interessant car il permet une utilisation mémoire bien moindre et ne nécessite pas de bascules en mode kernel intempestives, cependant lorsque le serveur est soumis à un nombre trop important de requêtes, les temps de réponse sont alors dégradés.
Concernant le nombre de process // threads, il est effectivement possible de déléguer certains traitements à des processus // threads fils. Par exemple, le processus père va poller la socket, mettre en attente les requêtes et des qu’il a de la disponibilité, au lieu de faire le traitement lui même, il va fork() un process en charge de la requête ou d’une partie de la requête.
L’avantage, avec de bons load balancers, une config kernel adéquate ( somaxconn pas trop haut, backlog etc … ) est que ce mode permet un excellent compromis en terme de ressources utilisées et de performances.

4 – Architectures en pipeline

Ce type d’architecture est assez méconnu, mais le principe est d’avoir des process // threads qui ne traitent qu’une partie précise de la requête par exemple … 1 process pour parser la requete, 1 process pour vérifier le cache, 1 process pour faire des access disques etc …
Les pipelines peuvent également être parallélisés.

Pour conclure, tu l’auras compris, j’ai envie de dire qu’il n’est pas pertinent de bencher des MPM, serveurs webs au fonctionnement aussi différents car ils répondent chacun à un besoin bien précis et dépendent énormément de la configuration mise en place.

Je suis tout à fait d’accord avec toi, il faut savoir de quoi on parle et ne pas se fier à tout ce qui peut être répété de part et d’autre du net, c’est pourquoi je tenais à préciser le fonctionnement de chaque architecture pour tes futurs lecteurs.
La popularité de Nginx vient principalement du fait qu’il monte en charge ( scale ) de manière beaucoup plus douce qu’un apache qui scale lui de manière exponentielle.
Lorsqu’on parle de performances, il faut distinguer la consommation de ressources système et les temps de réponse utilisateurs qui sont deux choses distinctes souvent confondues.
Donc je suis encore une fois d’accord avec toi pour dire que nginx n’est pas forcément plus performant que Apache, tout dépend du cas d’utilisation et des indicateurs qui vont définir la dite performance.