Journal [Benchmark] DragonFlyBSD plus performant dans sa version 3.2

Posté par  . Licence CC By‑SA.
Étiquettes :
3
5
nov.
2012

Concernant la dépêche sur DragonFlyBSD et sa nouvelle version, j'ai trouvé assez sympa le test de performance réalisé pour cette nouvelle monture.

Voici donc un petit résumé des pages, que je me suis permis d'établir.

Basé sur l'utilitaire pgbench, la page 1 établit la performance en projection de mémoire (mmap) selon le nombre de transactions effectuées à la seconde par rapport aux clients, en se basant sur une version de PostgreSQL 9.3-devel, un bi-Xéon X5650, et 24GB de mémoire. Ce que l'on remarque, c'est un gain significatif entre la version 3.0 de DragonFly, et sa dernière version 3.2 : 2 fois plus de transactions/seconde en moyenne jusqu'à 9 clients, et jusqu'à 28 fois plus avec 80 clients !
En fait, il y a une grosse baisse de performance à partir de 32 clients pour la version 3.0 de DragonFly.

La page 2 reprend les résultats du benchmark, plus une confrontation avec d'autres systèmes BSD (sauf openBSD) et un basé sur Redhat (Scientific Linux). je n'ai pas la raison du pourquoi OpenBSD n'est pas inclut dans le comparatif, mais si quelqu'un a la possibilité de faire les tests avec la même configuration matérielle…
Si NetBSD 6.0 montre de gros signex de faiblesse à partir de 18 clients, il sort du classement avec 32 clients (des process systèmes consommaient trop de temps cpu, même après la désactivation du process d'alimentation "powerd", suite au reboot dû au plantage pour une erreur critique: /etc/powerd/scripts/sensor_temperature: CRITICAL TEMPERATURE! SHUTTING DOWN. - bug reporté PR #46833).
Les seules distributions qui se montrent concurrentes sont DragonFly dans sa version 3.2, et Scientific Linux dans sa version 6.2 Ce dernier devient même plus performant que son premier homologue à partir de 24 clients (avec 80 clients, il le laisse à plus de 15000 transactions d’écart).

Enfin, la dernière page établit la configuration du test mis en place, ainsi que les commandes permettant d'effectuer le bench.

Il serait peut-être pertinent d'établir un nouveau bench avec une mesure plus large à d'autres OS, puisque le test s'est permis de ne pas se concentrer uniquement sur les distributions basées sur BSD.

Récapitulatif des liens:

  • # Ça ne serait pas la même chose qu'un journal récent

    Posté par  . Évalué à 4.

    https://linuxfr.org/users/djojo/journaux/toi-aussi-viens-prendre-un-cours-de-programmation-systeme

    • [^] # Re: Ça ne serait pas la même chose qu'un journal récent

      Posté par  . Évalué à 3.

      au temps pour moi, je me suis basé uniquement sur le journal récent, pensant que ce bench mettait en avant la sortie de la version 3.2, sans vérifié au préalable l’existence d'un post sur le sujet.

      • [^] # Re: Ça ne serait pas la même chose qu'un journal récent

        Posté par  (site web personnel) . Évalué à 6.

        AMHA ton journal est complémentaire car il décrit bien le bench et les résultats.

        • [^] # Re: Ça ne serait pas la même chose qu'un journal récent

          Posté par  . Évalué à -2. Dernière modification le 05 novembre 2012 à 19:24.

          Heu y'a absolument 0 information dans le journal qui ne soit pas dans le PDF. C'est quoi l’intérêt hormis de permettre aux aveugles d'y avoir accès via un screen reader ? Le journal avait lui l’intérêt de donner pas mal de pointeurs pertinents vers le ML pour avoir de l'information utile.

          Bientôt on va plébisciter la qualité et l'interet des dépêches AFP…

  • # Benchmark

    Posté par  . Évalué à 7.

    je voudrais juste commenter ce benchmark, qui circule pas mal et que les gens ont tendance à mal interpréter.

    Un benchmark, ça n'est utile que quand on sait ce qu'on mesure et qu'on sait que cette mesure a un sens. Je lis beaucoup de "dragonfly plus performant que X". Ça ne veut rien dire. Un benchmark, il faut le comprendre, il n'a aucune valeur en général.

    Dans ce cas, le benchmark mesure quoi ? L'éxécution de processus contenant des threads en parallèles, les processus étant deux à deux liés. De plus, c'est processus font beaucoup d'I/O. C'est donc un bench trés large qui dépend de la vitesse en lecture/écriture du FS, de la gestion des sockets UNIX, des semaphores posix, de la gestion des threads et du scheduling, et de la gestion de la mémoire partagée. Ça fait beaucoup, et on se rend bien compte que beaucoup de paramètres peuvent jouer, à commencer par les réglages par défaut du noyau utilisé.

    Ce qu'il a permi de mesurer avait un sens : le benchmark a été répété tout au lent du développement, après chaque changement. Il mesure donc l'impact sur les performances de chaque modifications, toutes choses étant égales par ailleurs. Pour comparer les versions, et identifier les goulot d'étranglement, c'est un bon benchmark.

    Comparer avec d'autres OS a moins de sens déjà, car beaucoup de paramètres diffèrent. Toutefois, ça peut donner une idindication sur les bottlenecks restants, et ça a quand même une valeur indicative dans le processus de développement, tout autant que motivante (on peut rattraper X, ça donne un objectif).

    Mais pour comparer les performances du point de vue d'un utilisateur, est ce que ça a un sens ? Je ne pense pas. Il s'agit purement d'un benchmark de développement : il s'intéresse à une charge particulière, qui n'a pas vraiment d'éxistense dans les conditions réelles : on ne fait jamais tourner un server par client, par exemple, ou le serveur risque d'avoir un socket TCP, et de toute manière, il faut avoir besoin d'un système qui monte à 200 000TPS.

    La comparaison avec les autres systèmes est donc à mon avis trés flottante et sans grande valeur. Il est tout à fait possible que FreeBSD atteigne d'aussi bon résultats en changeant quelques sysctl.

    • [^] # Re: Benchmark

      Posté par  . Évalué à 2.

      C'est exact: on peut souligner que ce benchmark trouve son intérêt dans le fait de démontrer, en quelque sorte, aux développeurs en charge de DragonFly que les modifications apportées depuis l'ancienne version ont eu un impact non négligeable sur la performance de PostGreSQL, en environnement "stressant".

      Après, certes si on se base sur une configuration plus ou moins optimisée des autres systèmes, on peut parvenir à de bons résultats, mais entre différents BSD, la différence devrait être moins perceptible. Elle l'est au contraire encore plus avec le plantage critique de NetBSD.

      Après, on peut aussi dire que cela va dans un but de rassurer les clients qui tournent (ou prévoient de tourner) sous DragonFly que la mise à jour est nécessaire pour profiter de meilleurs rendements dans les échanges sql.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.