Merci pour tes remarques et le temps passé que tu as passé sur le code.
Oui, c'est écrit en procédural, à l'ancienne. Le faire en objet, pourquoi pas, mais il n'y a pas vraiment d'intérêt dans ce cas-ci. Et puis comme ça c'est facile à suivre : ce qui sort à l'écran est relativement proportionnel au code, donc facile de trouver la partie du code qui affiche telle ou telle ligne.
Pour les display("[..] foo bar");, je trouve plus lisible de les avoir comme ça plutôt que d'avoir 4 fonctions display_ok("foo bar");, display_alert("foo bar"); ...
Mais la lisibilité, c'est sans doute quelque chose d'assez relatif, variable d'une personne à l'autre.
J'avoue que je n'ai pas compris le truc qui éviterait les readdir(), si tu peux détailler (idéalement avec un exemple) ... ça m'intéresse.
Pour les shell_exec(), il n'y a pas d'entrées utilisateur, pas de noms bizarres, donc j'ai en effet fait l'impasse sur les escapeshellarg(), fainéant que je suis.
Pour les regex, j'en ai parlé parce que ce script est pour moi un peu l'exception qui confirmerait ma règle (je code principalement des sites web). Je suis d'accord avec toi que dans le cas présent, l'usage de regex pourrait alléger le code, mais comme je n'ai pas l'habitude d'en écrire... ben voilà le résultat.
Les seuls tests hardcodés pour les threads, c'est ThreadsPerChild :
1- test si < 20, parce que moins de threads par process, c'est limiter le partage des allocations mémoire, ce qui est justement tout l'intérêt des threads (avec la vitesse de création par rapport à un fork de processus).
2- test si > 20000, qui est une valeur très très haute (valeur par defaut : 25). Confier 20000 threads à un seul processus, ça me fait penser à cette citation : "Celui qui avale une noix de coco entière fait confiance à son anus." Que le processus merdoie et c'est 20000 threads qui partent en sucette. Il serait probablement plus sage de réduire le nombre de threads et augmenter le nombre de processus. Mais 20000 est pifométrique, je suis prêt à changer pour une autre valeur s'il y a un retour d'expérience qui va dans ce sens.
Pour les MinSpareThreads et MaxSpareThreads, c'est fonction de la quantité de RAM et de l'activation d'HTTP/2.
Globalement, ce n'est pas évident de déterminer des seuils ou des valeurs adéquates pour un certain nombre de paramètres en se basant uniquement sur les données que le script peut choper dans mod_status et mod_info. Et puis il y a aussi une très grande diversité dans les uages d'Apache qui complique les choses.
Tu as tout bien compris : c'est un plaisir de le faire, et j'espère que ça aidera avant tout les gens qui ne maîtrisent pas du tout Apache. Les pros d'Apache (que je ne suis pas, d'ailleurs) n'y trouveront sans doute pas leur compte, mais je suis preneur de leurs remarques, comme des tiennes.
[^] # Re: Outil intéressant mais...
Posté par xulops (site web personnel) . En réponse au journal [PHP] Apache Check, première release. Évalué à 7.
Merci pour tes remarques et le temps passé que tu as passé sur le code.
Oui, c'est écrit en procédural, à l'ancienne. Le faire en objet, pourquoi pas, mais il n'y a pas vraiment d'intérêt dans ce cas-ci. Et puis comme ça c'est facile à suivre : ce qui sort à l'écran est relativement proportionnel au code, donc facile de trouver la partie du code qui affiche telle ou telle ligne.
Pour les
display("[..] foo bar");, je trouve plus lisible de les avoir comme ça plutôt que d'avoir 4 fonctionsdisplay_ok("foo bar");,display_alert("foo bar");...Mais la lisibilité, c'est sans doute quelque chose d'assez relatif, variable d'une personne à l'autre.
J'avoue que je n'ai pas compris le truc qui éviterait les
readdir(), si tu peux détailler (idéalement avec un exemple) ... ça m'intéresse.Pour les
shell_exec(), il n'y a pas d'entrées utilisateur, pas de noms bizarres, donc j'ai en effet fait l'impasse sur lesescapeshellarg(), fainéant que je suis.Pour les regex, j'en ai parlé parce que ce script est pour moi un peu l'exception qui confirmerait ma règle (je code principalement des sites web). Je suis d'accord avec toi que dans le cas présent, l'usage de regex pourrait alléger le code, mais comme je n'ai pas l'habitude d'en écrire... ben voilà le résultat.
Les seuls tests hardcodés pour les threads, c'est ThreadsPerChild :
1- test si < 20, parce que moins de threads par process, c'est limiter le partage des allocations mémoire, ce qui est justement tout l'intérêt des threads (avec la vitesse de création par rapport à un fork de processus).
2- test si > 20000, qui est une valeur très très haute (valeur par defaut : 25). Confier 20000 threads à un seul processus, ça me fait penser à cette citation : "Celui qui avale une noix de coco entière fait confiance à son anus." Que le processus merdoie et c'est 20000 threads qui partent en sucette. Il serait probablement plus sage de réduire le nombre de threads et augmenter le nombre de processus. Mais 20000 est pifométrique, je suis prêt à changer pour une autre valeur s'il y a un retour d'expérience qui va dans ce sens.
Pour les MinSpareThreads et MaxSpareThreads, c'est fonction de la quantité de RAM et de l'activation d'HTTP/2.
Globalement, ce n'est pas évident de déterminer des seuils ou des valeurs adéquates pour un certain nombre de paramètres en se basant uniquement sur les données que le script peut choper dans mod_status et mod_info. Et puis il y a aussi une très grande diversité dans les uages d'Apache qui complique les choses.
Tu as tout bien compris : c'est un plaisir de le faire, et j'espère que ça aidera avant tout les gens qui ne maîtrisent pas du tout Apache. Les pros d'Apache (que je ne suis pas, d'ailleurs) n'y trouveront sans doute pas leur compte, mais je suis preneur de leurs remarques, comme des tiennes.