Pages : 1
#1 Le 25/04/2026, à 13:44
- fnux
Bugs de wrk et wrk2 ?
Bonjour,
Utilisateur de différents serveurs web sous Linux pour répondre à différents besoins (dont Apache2, G-WAN, LiteSpeed et Nginx) sur différents types de machines (PC Intel et AMD, iMac, Raspberry Pi) , je teste systématiquement leurs performances respectives à chaque nouvelle version ou mise à jour de ces serveurs et/ou du système d'exploitation à l'aide des outils de benchmark bien connus : ab, wrk et wrk2 (ce que je viens encore de faire hier avec la dernière version LTS d'Ubuntu 26.04).
Mais après avoir récemment découvert la note de blog publiée sur le site de G-WAN, j'ai depuis les quatre questions suivantes aux quelles je ne trouve aucune réponse crédible :
1- comment wrk et wrk2 ont-il été si largement acceptés et diffusés avec de tels bugs ?
2- comment se fait-il que de tels bugs aient pu passer inaperçus pendant 14 ans ?
3- que font les gens sur github qui offrent du support pour wrk et wrk2 sans avoir jamais vu de tels bugs ?
4- quel crédit apporter aux auteurs (vu leur expertise) et mainteneurs de wrk et wrk2, à leurs partenaires, et à leurs sponsors qui les financent, car de telles incohérences dans les résultats obtenus ont été signalées depuis longtemps ?
Surtout quand on imagine sans peine que wrk2 n'a pas été écrit en vitesse sur un coin de table, ce travail ayant par ailleurs fait l'objet d'une documentation hors normes par son niveau de détail et de temps consacré à cet outil : https://deepwiki.com/giltene/wrk2/2.1-b … ution-flow
Note de blog du site de G-WAN : http://gwan.com/blog/20260414.html
SVP, quelqu'un (aura-t-il l'audace et le courage) peut-il m'apporter des réponses avisées et argumentées à ces 4 questions pour contrecarrer une petite idée préconçue ? 
Merci d'avance.
Bien cordialement et bon week-end.
Fnux
Dernière modification par fnux (Le 25/04/2026, à 22:56)
N'engage pas un débat lors d'un dîner car celui qui n'a pas faim aura le dernier mot. - R. Whately
Hors ligne
#2 Le 25/04/2026, à 14:44
- fnux
Re : Bugs de wrk et wrk2 ?
PS : pour ceux que cela intéresse, je peux fournir la version complète (sources, dépendances, makefile et exécutable) et corrigée de wrk2 maintenant appelée wrk3 pour cpu ARM et Raspberry PI (compilée et testée sur mon Pi 500+), celle pour cpu Intel et AMD étant disponible dans la note de blog citée dans mon post précédent (cherchez le lien de téléchargement en gris clair souligné dans le bas de cette note de blog).
Merci de bien vouloir m'en faire la demande par e-mail sur fnux.fl@gmail.com
Cheers.
Fnux
Dernière modification par fnux (Le 25/04/2026, à 14:59)
N'engage pas un débat lors d'un dîner car celui qui n'a pas faim aura le dernier mot. - R. Whately
Hors ligne
#3 Le 26/04/2026, à 23:05
- krodelabestiole
Re : Bugs de wrk et wrk2 ?
je ne connais pas wrk.
si je devais conseiller un serveur HTTP sur lequel il serait intéressant de se pencher aujourd’hui, ce serait plutôt caddy https://caddyserver.com/
il faut aussi savoir que les performances d'un serveur HTTP en lui-même sont négligeables. ça se compte en microsecondes.
ce qui change réellement les choses c'est le moteur CGI qui interprète généralement un script.
on compare généralement apache à nginx en utilisant Apache avec le module Apache-PHP, alors que nginx n'a pas de module de ce type, donc avec PHP-FPM. ça n'a pas de sens, et on en conclut que nginx est beaucoup plus performant.
si on utilise Apache avec PHP-FPM la différence est négligeable.
(donc attention à ça, au cas ou...)
nouveau forum ubuntu-fr on en parle là : refonte du site / nouveau design
profil - sujets récurrents - sources du site
Hors ligne
#4 Le 03/05/2026, à 03:24
- fnux
Re : Bugs de wrk et wrk2 ?
Bonjour krodelabestiole et merci de ta réponse.
je ne connais pas wrk.
Tu ne perds pas grand chose tellement WRK et WRK2 sont buggés, pour ne pas dire truqués pour avantager certains outis et en disqualifier d'autres (preuves à l'appui) !
Malgré ses nombreux forks, la famille des outils wrk/wrk2 a été (très mal) écrite pour mesurer la capacité de la résistance à la montée en charge des requêtes des clients de serveurs web et jusqu'à présent n'a jamais été corrigée bien que leurs auteurs respectifs aient été avertis depuis longtemps des incohérences des résultats obtenus ! 
Leurs problèmes sont multiples en raison a) d'une architecture inadaptée au sujet, b) de l'utilisation de LUA et de nombreuses dépendances peu efficaces quand elles ne sont pas elles mêmes (plus ou moins) buggées (ou très dépendantes de la version de l'OS comme par exemple gcc), de leur lenteur, de leur consommation délirante de ressources, et surtout de bugs (plus ou moins) volontaires !
si je devais conseiller un serveur HTTP sur lequel il serait intéressant de se pencher aujourd’hui, ce serait plutôt caddy https://caddyserver.com/
Merci pour le lien car je ne connais pas Caddy et je vais y jeter un coup d'oeil pour voir s'il apporte quelque chose par rapport à l'environnement de test de prédilection actuellement sélectionné par le client (machines à CPU ARM64 du genre MacMini M4 ou même Raspberry Pi 500 et autres nano computers de ce type).
il faut aussi savoir que les performances d'un serveur HTTP en lui-même sont négligeables. ça se compte en microsecondes.
ce qui change réellement les choses c'est le moteur CGI qui interprète généralement un script.
on compare généralement apache à nginx en utilisant Apache avec le module Apache-PHP, alors que nginx n'a pas de module de ce type, donc avec PHP-FPM. ça n'a pas de sens, et on en conclut que nginx est beaucoup plus performant.
si on utilise Apache avec PHP-FPM la différence est négligeable.
(donc attention à ça, au cas ou...)
Désolé, mais la résistance aux montées en charge des requêtes envoyées aux serveurs web (http ou https) est totalement indépendante des modules installés pour exécuter les scripts côté serveur (C#, Go, Java, NodeJs, PHP ou autres) et ne dépend que de la réactivité du logiciel serveur web lui même, qu'il utilise un cache ou non, et qu'il soit installé derrière un reverse proxy serveur ou pas.
Ces tests peuvent donc être réalisés par des requêtes multiples croissantes en très grand nombre (de 1 à 50.000) d'un nombre lui aussi croissant d'utilisateurs (de 1 à 50.000) et sur une durée significative (de 1 à 30 minutes) d'un simple fichier complexe de 100 octets, ce qui élimine le côté de la latence de l'interprétation et de l'exécution des scripts.
Et ces mesures sont extrêmement importantes (quand elles ne sont pas fausses ou pire truquées) pour déterminer le type et le nombre de machines (bare metal) et le type de logiciel serveur installé dont on peut avoir besoin par exemple pour créer une ferme de serveurs avec tout ce que cela implique (taille du bâtiment, consommation électrique, besoin de refroidissement, nombre de personnes pour suivre et maintenir l'ensemble des systèmes, etc. etc. etc.).
D'où l’intérêt d'avoir au strict minimum un outils de mesure qui ne soit pas buggé (ou pire truqué) tel que celui corrigé au strict minimum qui s'appelle maintenant wrk3 et qui est disponible aussi bien pour les architectures ARM que X86-64 (Intel et AMD).
Cependant, si pour l'instant wrk3 corrige à minima les résultats affichés en donnant de vraies valeurs non buggées (wrk) et non volontairement truquées (wrk2), il n'est pas recommandé de l'utiliser pour pouvoir réellement tester vraiment à fond n'importe quel serveur web tant il est lent et que sa consommation de ressources RAM est hallucinante !
En effet, si l'outil de mesure est plus lent que le serveur web qu'il teste, voir pire s'arrête faute de ressources disponibles, c'est alors l'outil de mesure qui est le bouchon d'étranglement, pas le serveur web testé !
N'importe qui ayant ce minimum de connaissance système ne pourra qu'approuver (et je ne suis même pas un développeur professionnel). 
Just my six cents (and no longer two cents, given the rise in the price of a barrel of oil) 
Dernière modification par fnux (Le 05/05/2026, à 00:44)
N'engage pas un débat lors d'un dîner car celui qui n'a pas faim aura le dernier mot. - R. Whately
Hors ligne
Pages : 1