Sun T2000 contre Apple Mac Pro, contre Linux, fin des tests

J'ai fini par boucler mes modestes tests de charge MySQL 4.x sur la Sun T2000, le Mac Pro d'Apple, et un serveur Supermicro 6015P-TR sous linux. Comme je n'ai utilisé que super-smack à cause de fortes contraintes temporelles (entre autre), les résultats ne sont pas forcément généralisables, ni applicables à toutes les architectures. Néanmoins j'ai obtenu quelques résultats intéressants.

Machines Utilisées

Pour ces benchmarks, j'ai utilisé 3 machines différentes : un serveur Sun T2000, un Apple Mac Pro, et un Supermicro 6015P-TR. Les caractéristiques matérielles et logicielles sont les suivantes :
Sun T2000 : 1 processeur T1 à 1.0 GHz, 8 cores physiques, 4 threads par core, donc 32 processeurs virtuels au total.
8 Go de RAM, 2 disque durs SAS, réseau gigabit switché, Solaris 10 64 bits, et MySQL 4.0.24 installé par Sun.
Apple Mac Pro : 2 processeurs Xeon Woodcrest 2,66 GHz, 2 cores par processeur, donc 4 processeurs physiques.
7 Go de RAM, 4 disques durs SATA (un seul utilisé), réseau gigabit switché, MacOS X Serveur 10.4.8 64 bits, et MySQL 4.1 64 bits fourni avec le système. Cette machine est un substitut de XServe Intel, car ces derniers n'étaient pas disponibles au moment des tests.
Supermicro 6015P-TR : 2 processeurs Xeon Woodcrest 3.0 GHz, 2 cores par processeur, donc 4 processeurs physiques.
8 Go de RAM, 4 disques durs SATA Raptor (un seul utilisé), réseau gigabit switché, Linux Debian AMD64 "testing" 64 bits, MySQL 4.1.21-standard-log 64 bits, téléchargé sur mysql.com (mysql-standard-4.1.21-unknown-linux-gnu-x86_64-glibc23).

Configuration

Toutes les installations de MySQL sont faites avec des versions "vendeur", soit les installations système par défaut, soit les binaires officiels de mysql.com. Plusieurs configurations différentes ont été testées côté serveur. Pendant tous les tests, le format de base par défaut a été réglé sur innodb :

default_table_type = INNODB

Le serveur doit autoriser la connexion locale et la connexion réseau :

port = 3306 
socket = /tmp/mysql.sock

Les variables modifiées au cours des différents tests sont :

back_log = 100 
thread_cache = 150 
thread_concurrency = 32

Trois groupes de configurations ont été basés sur des variations de ces paramètres : small (20/50/8), big (20,150,16), et bigger (100/150/32). La base de la configuration pour les autres paramètres est constante d'un test à l'autre et repose sur un fichier d'exemple de mysql modifié (my-innodb-heavy-4G.cnf). Tous les tests ont donné des résultats identiques pour les configurations small, big et bigger, donc dans le reste de ce document on ne se souciera plus de la configuration MySQL, les trois étant équivalentes vis à vis du logiciel de benchmark.
Du fait que le MySQL fourni avec Solaris est en version 4.0.x, nous avons du ajouter à la configuration des MySQL 4.1.x de Mac OS X Serveur et de Linux la directive permettant d'utiliser une implémentation des mots de passe "compatible 4.0" :

old-passwords

Mise en place des tests

Par manque de temps, et de connaissances spécifiques à Solaris, j'ai réduit le nombre des logiciels de test à un. Le choix s'est porté sur un outils relativement basique mais largement employé par ailleurs : super-smack 1.3.
Ce logiciel utilise deux fichiers de configuration pour deux tests différents. Le premier test est un SELECT pur. Le second test fait un SELECT, puis un UPDATE. J'ai gardé les fichiers de configuration dans leur état d'origine sauf pour les données relatives aux adresses de serveur, et aux mots de passe de connexion. Le test "select" est lancé avec un nombre de clients variant de 1 à 80, et produit 10000 "select" par itération :

i=0 
while [ $i -lt 80 ] 
do 
    i=$((i+1)) 
    super-smack sql_select-key.smack $i 10000 >> select-key_${i}.out 
done 

Le test "select-update" est lancé avec un nombre de clients variant de 1 à 80, et produit 1000 "select" et 1000 "update" par itération :

j=0 
while [ $j -lt 80 ] 
do 
    j=$((j+1)) 
    super-smack sql_update-select.smack $j 1000 >> update-select_${j}.out 
done 

Ces deux batteries de tests sont lancées 5 fois de suite, et on calcule une moyenne de chaque résultat sur ces 5 mesures.
Il est intéressant de noter que super-smack produit non pas des "threads" clients mais bel et bien des processus. Donc quand super-smack arrive à 80 clients, ce sont 80 processus super-smack qui attaquent le serveur MySQL.

Résultats

Ce premier graphique donne les résultats du test "select" pour différents couples client-serveur.

client et serveur linux, même machine : le client super-smack et le serveur MySQL tournent sur la même machine, les connexions se font par le socket unix. C'est le cas idéal d'après les chiffres obtenus. Le pic de performance est atteint pour 4 processus clients, ensuite, les performances décroissent lentement tout en restant au dessus de 52000 selects/seconde face à 80 clients. Cela montre la très bonne gestion des threads et des processus multiples par linux.

client et serveur Mac OS X, même machine : c'est le pire cas testé. Le pic de performance est à 2 processus clients, ce qui laisse 2 processeurs pour le serveur MySQL. Par rapport à la machine Supermicro, la puissance brut des processeurs est inférieure de seulement 12%, alors que les performances sont globalement 5 fois moins bonnes. Cela montre l'énorme retard de Mac OS X en terme de gestion de threads et de processus multiples face à des systèmes comme linux et Solaris.

client et serveur sun, même machine : c'est un cas intermédiaire. Le pic de performance est atteint autour de 12 clients, puis le nombre de requêtes par seconde reste stable jusqu'à 80 clients concurrents. client sun et serveur Mac OS X : avec un peu moins de 35K requêtes par secondes, ce couple donne des résultats 3 fois meilleurs que quand le client et le serveur sont sur le même Mac OS X.

client sun et serveur linux : c'est à peu près 12% de mieux que le couple sun-mac, ce qui correspond à la différence de puissance brute entre le serveur Supermicro et le serveur Apple.

client linux et serveur sun : c'est un résultat atypique, car il est presque identique au résultat obtenu avec le client et le serveur sur la machine sun. La similitude de ces résultats pourrait montrer à la fois la très grande qualité de multi-tasking et multithreading du couple Solaris 10 / processeur T1, ainsi que la limite imposée par la relative faible performance brute du processeurs T1 (1 GHz).

Ce second graphique est un peu plus chaotique. Il présente les résultats du test "select-update" pour les mêmes couples de clients et serveurs.

client et serveur linux, même machine : comme pour le test précédent, le départ est très bon. Par la suite de fortes oscillations se produisent avec une stabilisation progressive vers une moyenne à plus de 10K select+update/secondes. La courbe en dents de scie est peut être attribuable à la gestion des écritures sur le disques. C'est encore cette fois la combinaison qui donne les meilleurs résultats, à égalité avec le couple client sun et serveur linux.

client et serveur Mac OS X, même machine : ce n'est plus tout à fait une catastrophe. Cette combinaison fait 2 fois moins bien que le linux sur lui même, pour 12% de puissance brute en moins.

client et serveur sun, même machine et client linux et serveur sun : ce sont les deux cas les moins favorables, mais le système de fichier n'a pas été du tout optimisé, donc c'est un facteur pénalisant potentiel pour les écritures. client sun et serveur Mac OS X : un peu moins des deux tiers du score obtenu par la combinaison client-serveur linux. L'écart avec la combinaison client-serveur mac est relativement faible.

Conclusion avec jolis graphiques pour décideur pressé

select par seconde, tcpLa combinaison idéale pour un serveur MySQL dédié est donc sans doute un Mac OS X Server sur XServe Intel, à condition que la base de données soit utilisée à majorité en lecture. Il a pour lui la facilité d'administration, et de bonnes performances (ci-contre, nombre de SELECT par seconde pour chaque machine soumise à 4, 40 et 80 clients concurrents connectés par TCP).

select+update par seconde, tcpSi les performances d'écriture sont importantes pour l'application, le Supermicro sous linux est le meilleur choix, bien que le XServe Intel doivent être testé pour évaluer l'impact du SAS sur les performances d'écriture (ci-contre, nombre de SELECT+UPDATE par seconde pour chaque machine soumise à 4, 40 et 80 clients concurrents connectés par TCP).

La Sun T2000 aurait mérité un professionnel de Solaris pour un réglage fin du réseau et du système de fichier. Néanmoins, la stabilité des performances est excellente. C'est une bonne machine pour des requêtes demandant peu de puissance de calcul et devant gérer une forte concurrence de connections.

select par seconde, socket unixPour une machine "tout en un", type serveur LAMP, linux sur Xeon Woodcrest offre les meilleurs performances, incontestablement. Cette solution n'a pas néanmoins la robustesse d'une offre intégrée telle que la Sun T2000 avec Solaris 10, et elle nécessite un peu de bricolage pour être opérationnelle. Elle est par contre moins coûteuse que la T2000, mais consomme sensiblement plus de puissance électrique (ci-contre, nombre de SELECT par seconde pour chaque machine soumise à 4, 40 et 80 clients concurrents connectés par socket Unix).

édit. ortho et mise en page

Related posts

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.