Le gars ne donne aucun détail sur les conditions de ses benchs : version du bench, type de machine (raid ou pas, qté de ram, configs, systèmes de fichiers utilisés, params passés aux outils de benchs, etc), ils ne sont pas reproductibles en l'état.
Je ne connais pas hackbench ni les détails de son test build.sh. Mais au moins concernant sysbench, qui est effectivement un bench très reconnu, les petits détails de paramétrage ont un impact notoirement significatifs (et connus pour être différents selon les OS, justement...).
Par ex. certains OS s'écroulent très vite si on augmente trop le innodb_thread_concurrency, mais peuvent tenir la même charge que d'autres si on le configure avec justesse.
Ou encore : sous linux, les différences de résultat sur ce test (en fait, sur tout les benchs OLTP / de SGBD) entre l'ordonanceur d'E/S cfq (par défaut sous Linux, très bien pour le desktop mais très mauvais pour les bdd) et le deadline (plus adapté) sont immenses. Et bien sûr la proportion entre la taille des bases et le cache (innodb_buffer_pool_size) change complètement le sens du test (si le cache est assez grand, on mesure réellement les perfs du scheduler CPU, de VM, de l'implémentation du threading, s'il est petit on mesure les perfs des drivers block/raid, du scheduler d'I/O et du système de fichier). La méthode de flush des dirty pages a aussi un impact important (sous Linux, utiliser O_DIRECT améliore significativement les résultats).
# Méthodologie ?
Posté par herodiade . En réponse au journal Benchmark NetBSD5, NetBSD4, Fedora et FreeBSD. Évalué à 7.
Je ne connais pas hackbench ni les détails de son test build.sh. Mais au moins concernant sysbench, qui est effectivement un bench très reconnu, les petits détails de paramétrage ont un impact notoirement significatifs (et connus pour être différents selon les OS, justement...).
Par ex. certains OS s'écroulent très vite si on augmente trop le innodb_thread_concurrency, mais peuvent tenir la même charge que d'autres si on le configure avec justesse.
Ou encore : sous linux, les différences de résultat sur ce test (en fait, sur tout les benchs OLTP / de SGBD) entre l'ordonanceur d'E/S cfq (par défaut sous Linux, très bien pour le desktop mais très mauvais pour les bdd) et le deadline (plus adapté) sont immenses. Et bien sûr la proportion entre la taille des bases et le cache (innodb_buffer_pool_size) change complètement le sens du test (si le cache est assez grand, on mesure réellement les perfs du scheduler CPU, de VM, de l'implémentation du threading, s'il est petit on mesure les perfs des drivers block/raid, du scheduler d'I/O et du système de fichier). La méthode de flush des dirty pages a aussi un impact important (sous Linux, utiliser O_DIRECT améliore significativement les résultats).