Quand vous avez un millier de chaînes de caractères, dont vous souhaitez retrouver toutes les occurrences dans un gros fichier de 685000 lignes, vous pouvez utiliser grep de deux manières :

1. vous dites à votre ami grep de chercher toutes les chaînes en même temps dans le gros fichier,
2. vous utilisez une boucle pour dire à grep de chercher une chaîne dans le fichier, puis de passer à la chaîne suivante, …

La solution 1 semble la plus intéressante. Une seule commande, pas de boucle, on se dit naturellement que c'est plus économique, et donc plus rapide. La solution 2, on se dit qu'elle est moche, complexe, et que les performances vont être mauvaises.

Petit test grandeur nature sur un serveur FreeBSD 7.x virtualisé, 2 CPU, 2Go de RAM :

Méthode 1 :
grep -i -f liste_emails maillog
opération terminée en 370 min environ.
Méthode 2 :
while read email; do grep -i $email maillog ; done<liste_emails
opération terminée en 1 min 32 s.

Bien sûr, le résultat est le même en terme de contenu, la seule différence est l'ordre des lignes. La méthode moche et supposée lente est juste 240 fois plus rapide que la méthode académique. Shame on you grep. Shame on you.

L'environnement est aussi important. On pourrait se dire qu'avec plus de CPU (en puissance, pas en nombre), plus de RAM, tout irait tellement plus vite. Essayons la même chose sur un Mac Pro Xeon quad-core, avec 12 Go de RAM, sous Mac OS X 10.6.

Méthode 1 : 223 min.
Méthode 2 : 35 min 45 s.

Ce qui prouve une fois de plus que Mac OS X est un gros tromblon quand il s'agit de fork. Comprendre que le coût du lancement d'un programme, en terme de ressources système, est beaucoup plus fort que sur d'autres OS, comme FreeBSD par exemple. Ce qui fait de Mac OS X un très mauvais candidat pour les scripts shell utilisant des boucles de manière très intensive.
On voit aussi que la vitesse d'exécution de la méthode 1 est essentiellement liée à la puissance de calcul du CPU, alors que la vitesse de la méthode 2 est essentiellement liée à la capacité du système d'exploitation de créer des process rapidement.

Pour conclure, j'ai fait un petit test avec awk, sur les mêmes fichiers. Moyennant quelques aménagements triviaux pour transformer le fichier liste_emails en programme awk, j'ai pu lancer la commande awk -f liste_emails maillog qui est l'équivalent de la méthode 1 pour grep. Le temps d'exécution est tombé à moins de 15 minutes sur Mac OS X, et moins de 30 minutes sur le FreeBSD.

* ceux qui ont fait 5 ans d'études dans une autre branche, avant de passer à l'informatique, par exemple.

Pour faire un benchmark L4D2 sur PC ou Mac, il faut procéder à plusieurs manipulations que je ne vais pas détailler. Sachez juste qu'il faut activer la console développeur dans les préférences du jeu. Grace à cette console, vous allez pouvoir enregistrer une "demo", c'est à dire le script d'une partie. Ensuite il faut rejouer ce script avec différents réglages vidéo, et enregistrer le nombre d'images par seconde que votre machine génère pendant le rendu vidéo de cette "demo". C'est long et fastidieux, et il est impossible (et stupide) de tester tous les réglages vidéo. Si j'avais voulu faire une mesure pour chaque combinaison de réglages, sans changer la résolution, il aurait fallu que je fasse 2700 rendus de ma partie enregistrée.

J'ai donc pris le parti de lancer 5 fois la partie enregistrée, toujours dans la même résolution (1920x1200), et toujours avec les paramètres "effects" et "model" au maximum.

Voici le résultat sous la forme d'un graphique :

En rouge, est représenté le pourcentage d'images qui sont calculées à la vitesse de 60 images par seconde ou plus. Donc plus la proportion de rouge est grande, plus la carte video calcule vite le rendu de la partie. Et plus la proportion de vert et de bleu est faible, moins vous avez de ralentissements perceptibles dans le rafraîchissement de l'image. Ici le bleu (moins de 20 fps) est totalement absent.
Le jeu est capable d'afficher des chiffres de FPS ("frame per second") supérieurs à 60, mais le système intégré qui enregistre la répartition des FPS considère qu'à partir de 60 images par seconde il n'est plus utile de donner la répartition des FPS.
Ce n'est pas gênant, car in fine, les écrans actuels sont assez limités en terme de rafraîchissement, et que 60 images par seconde, c'est suffisant pour un affichage stéréoscopique à 30 images par seconde pour chaque œil. Donc à partir de 60 FPS, même un joueur exigeant pourrait jouer avec des lunettes 3D confortablement.

On voit sur ce graphique qu'un réglage a énormément d'impact sur le nombre de FPS : la synchronisation verticale. Si la synchronisation verticale est activée, le jeu ne peut pas dépasser 60 images par secondes, et le nombre global de FPS est sensiblement réduit. Mais ce réglage garanti une certaine cohérence de l'affichage et prévient l'apparition d'artefacts graphiques qui peuvent dénaturer l'expérience du joueur. Si votre machine le permet, laissez la synchronisation verticale activée. Les réglages 3 et 4 montrent l'impact de la désactivation de cette synchronisation sur la répartition des FPS.

Je ne vais pas plus loin dans l'analyse, il est aisé de comparer chaque jeu de réglages en utilisant le graphique. Si vous souhaitez faire le même benchmark que moi exactement, il vous faut le script de la partie que j'ai enregistré (ZIP 3,6Mo). La partie dure environ 10 minutes. L'archive contient un fichier parish000.dem qui est le script de la partie, et un fichier parish000.vdm qui est un fichier texte contenant les commandes qui lancent l'enregistrement des FPS au début du rendu, et qui arrêtent l'enregistrement à la fin du rendu. Il faut placer ces deux fichiers dans /left 4 dead 2/left4dead2 (je ne donne pas le chemin complet il est différent sur Mac OS X et Windows).
Après avoir joué la partie sur votre machine, vous obtiendrez un fichier prof_c5m4_quarter.csv situé dans /left 4 dead 2/update/. Attention, ce fichier est écrasé à chaque lancement de la "demo".
Je vous renvoie vers les forums et les aides en ligne pour tous les détails techniques (comment lancer une "demo", etc.).

Addendum

À titre de comparaison, voici le même benchmark effectué sur un MacBook Pro (un portable donc), doté d'un Core Duo 2,8 GHz, de 8 Go de RAM DDR3, et d'une carte vidéo GeForce 9600M GT. La résolution est native : 1440x900. J'ai tenté de faire le test avec les réglages vidéo "recommandés" par le jeu, l'écriture du fichier de log des FPS a échoué, mais les résultats étaient de toute manière catastrophiques.

À gauche, un jeu de réglages "tout medium" avec antialiasing et filtering au minimum. Au centre, les mêmes réglages mais avec la synchronisation verticale désactivée. Enfin à droite le jeu de réglages "recommandés" par L4D2, mais avec la synchronisation verticale désactivée. Le résultat reste injouable, avec presque 75% des frames générées à moins de 20 fps.

La méthodologie de ces tests est sommaire et barbare. J'ai choisi d'utiliser la commande dd pour lire et écrire des fichiers de 500 et 800 Mo sur les deux cartes. Le lecteur est connecté en FireWire 2 (800 Mbits/s théoriques, soient 100 Mo/s). Voici un exemple de commande utilisée pour l'écriture :

time dd if=/dev/zero bs=8k count=100000 of=/Volumes/EOS_DIGITAL/fichier

et un exemple de commande utilisée pour la lecture :

time dd bs=64k if=/Volumes/EOS_DIGITAL/fichier | dd of=/dev/null

Résultats d'écriture

• 12,43 Mo/s pour la carte Ultra II
• 30,42 Mo/s pour la carte Extreme IV

Résultats de lecture

• 13,17 Mo/s pour la carte Ultra II
• 64,93 Mo/s pour la carte Extreme IV

Je n'ai pas torturé les cartes pour en tirer les meilleurs performances, mais l'Extreme IV se dégage sans difficulté devant l'Ultra II avec des performances de lecture dépassant nettement les 40 Mo/s annoncés par le constructeur. Ce résultat est hautement suspect. J'ai donc refait le test de lecture de la carte Extreme IV avec des vrais fichiers RAW.

for image in /Volumes/EOS_DIGITAL/*.CR2; do
   time dd bs=64k if=${image} | dd of=/dev/null
done

La première exécution de cette commande donne environ 33 Mo/s pour les 39 fichiers RAW. La seconde lecture donne par contre une moyenne de 74 Mo/s. Sans doute une farce de l'OS (Mac OS X 10.5.2) et de ses multiples caches d'optimisation/accélération.
Dans le cadre de l'utilisation photographique d'une carte CF, l'ordinateur avec son lecteur externe va servir à télécharger les photos une fois, et effacer la carte. On peut donc oublier les résultats farfelus et ne retenir que le déjà très honorable 33 Mo/s.
Pour utiliser régulièrement cette carte avec de lecteur pour décharger mes photos, je peux témoigner du confort énorme qu'apporte ces performances.

30 jpeg

• 17 sec. sur l'Ultra II
• 12 sec. sur l'Extreme IV (29,4% plus rapide | lesnumeriques.com : 35,2% avec 11")

30 RAW+jpeg

• 56 sec. sur l'Ultra II
• 52 sec. sur l'Extreme IV (7,1% plus rapide | lesnumeriques.com : 21,4% avec 44")

Si le test "jpeg" donne un résultat assez proche de celui de référence, le test "RAW+jpeg" est sensiblement moins bon. Il sera peut être nécessaire de refaire le test complètement sans reprendre les vieux résultats de l'Ultra II. Néanmoins, les écarts de performance que je constate entre l'Ultra et l'Extreme étant plus faibles que ceux qu'avance lesnumeriques.com, cela confirmerait que l'EOS 350D est bien le facteur limitant comme le disent plusieurs sites dédiés à la photographie.

Pour compléter ce test, je me suis livré à un second comparatif. En inversant la méthodologie j'ai décidé de mesurer le nombre de photos prises en un temps donné. Voici donc pour chaque carte le nombre de jpeg, raw, et raw+jpeg enregistrés en 10 et 30 secondes :

jpeg haute qualité

• 63 en 30" et 27 en 10" sur l'Ultra II
• 64 en 30" et 29 en 10" sur l'Extreme IV

RAW

• 32 en 30" et 13 en 10" sur l'Ultra II
• 32 en 30" et 14 en 10" sur l'Extreme IV

RAW+jpeg

• 21 en 30" et 09 en 10" sur l'Ultra II
• 21 en 30" et 10 en 10" sur l'Extreme IV

Les résultats sont pour ainsi dire totalement identiques d'une carte à l'autre. La carte Extreme IV garde un très maigre avantage sur 10 secondes, mais sur 30 secondes elle fait jeu égal avec l'Ultra II dans un EOS 350D. C'est intéressant de voir comme les deux méthodologies de test donnent des résultats si différents pour les mêmes cartes testées dans le même boîtier. Ce dernier test montre encore mieux que le premier la limitation imposée par l'appareil numérique

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é

La 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).

Si 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.

Pour 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

Comme précédemment, le but est de mettre en face du serveur MySQL de la T2000, un client capable de mettre à genoux la machine Sun.
On a vu qu'un client XServe bi G5 à 2 GHz n'est pas assez puissant pour faire chauffer le serveur. Au plus fort de mes tests j'ai dépassé 90 de charge sur le XServe, et la T2000 n'a jamais atteint les 20% cpu. Le nombre de selects par seconde, obtenu via super-smack sql_select-key.smack $i 10000 (avec $i un nombre de threads entre 1 et 80), plafonne à 13400 ±300.
Dans les mêmes conditions, le client Mac Pro arrive à tirer 26700 ±200 selects par seconde du serveur Sun. Pendant cette charge de threads et de requêtes, le MySQL consomme 16% du cpu sur le serveur. À moins de faire une attaque distribuée à partir de plusieurs clients, je ne vois aucun moyen de mettre la T2000 en échec, ce qui est bon signe si je veux remplacer nos trois XServes/MySQL par une seule T2000/MySQL.

root@sunt2000 # psrinfo -pv
The physical processor has 32 virtual processors (0, 1, 2, 3, 4, 5, 6, 7, 8,
9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28,
 29, 30, 31)
  UltraSPARC-T1 (cpuid 0 clock 1000 MHz)

Et bien, le XServe mouline comme un taré (actuellement Load Avg: 15.14, 13.33, 9.61, et ça monte), alors que la SUN ne fait presque rien :

   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
   935 mysql    2565M  856M cpu9    45    0   2:37:15 6.1% mysqld/25
../..
Total: 45 processes, 188 lwps, load averages: 2.78, 2.77, 2.50

Je reviendrai là dessus quand je serai un peu plus familier avec Solaris d'une part et les méthodes de bench MySQL d'autre part, mais j'ai dans l'idée que les 60 jours vont très vite passer.

La question de la consommation électrique est aussi abordée : le quad-core xeon 2.66 GHz consomme sensiblement moins que le quad G5 2.5 GHz en plein travail, mais je trouve la comparaison douteuse. La pompe de refroidissement liquide du quad G5 doit probablement consommer plus qu'un ventilateur.