Sur le plan de la configuration initiale, Nuxeo est aussi en tête. Une fois l'application lancée, on s'y connecte, et on personnalise les réglages via l'interface web directement. Du côté d'Alfresco, rien n'est prévu pour faciliter la configuration au moment du déploiement. Il faut éditer un fichier de configuration à la main dans le quel on indique des chemins de fichiers, des informations de connexions pour le serveur de bases de données, etc. De même seul Nuxeo prévoit un menu d'administration complet gérant entre autres choses les patch de mises à jour, et le redémarrage de l'application.

Mais tout ça n'est pas grand chose. Finalement, on ne passe pas son temps à installer et configurer une application. La différence se fait sur l'usage.

En terme d'ergonomie, c'est Nuxeo qui remporte la palme. L'interface est enrichie de fonctions en AJAX, qui permettent par exemple de déplacer un document d'une catégorie à une autre par glisser-déposer, ou bien d'envoyer des documents directement à partir de votre ordinateur vers Nuxeo. Alfresco quant à lui est très en dessous. Tout d'abord il est livré sous la forme de deux applications Alfresco d'un côté, et Share de l'autre. La première se rapproche un peu de Nuxeo DM, mais sans l'AJAX. Pour faire la moindre choses il faut multiplier les clics, c'est assez pénible. La seconde, Share, est plutôt orientée utilisateur final, publication, média "sociaux". Elle propose l'import de documents par glissé-déposé comme Nuxeo, mais elle manque de sobriété. Les documents sont présentés par défaut sous forme de liste de grosses icones aussi inélégantes qu'encombrantes. De nombreuses actions peuvent être faites aussi bien dans Alfresco que dans Share, mais pas toutes. Par exemple je peux utiliser des noms de tags dans le champs de recherche de Share, alors que cela ne fonctionne pas dans Alfresco. Finalement quand on veut faire quelque chose, il faut d'abord se souvenir dans la quelle des deux applications c'est possible (et le plus simple) et s'y connecter. C'est juste n'importe quoi.

La recherche des documents est aussi une dimension importante de la GED. Elle repose sur une indexation du contenu des documents, sur des métadonnées, sur une organisation. J'ai tendance à considérer que l'organisation physique des documents ne doit pas trop peser dans la balance. Il n'y a qu'une manière de classer une facture médicale. Doit-on la ranger dans le dossier "facture", dans le dossier "facture" du dossier "santé" ou dans le dossier "santé" du dossier "facture" ?
Je préfère de loin un système de tags ou de catégories qui me permette d'accoler plus d'une étiquette à un document, et surtout de retrouver tel ou tel document en combinant ces étiquettes dans un champ de recherche. Les tags dans Nuxeo sont assez accessibles. On en ajoute facilement, mais je ne peux pas chercher un document en tapant un ou plusieurs tags dans le champs de recherche. Les tags sont très bien cachés dans Alfresco, et ils sont inutilisables par défaut. A contrario, sans Share les tags sont accessibles, et on peut les utiliser facilement pour une recherche. Malheureusement, il est alors impossible de préciser qu'on souhaite chercher uniquement dans les tags, ce qui réduit l'intérêt de la chose.

La gestion des sauvegardes d'un entrepôt de données est primordiale. Nuxeo étant par défaut entièrement inclus dans un répertoire unique, il n'y a que deux choses importantes à sauvegarder pour que l'application puisse repartir rapidement en cas de désastre : le répertoire de l'application, et la base de données. J'ai déjà un script qui sauvegarde automatiquement mes bases MySQL, mais comme expliqué plus haut, MySQL n'est pas une option. Garder Nuxeo impliquerait donc d'apprendre à gérer des sauvegardes PostgreSQL (dump, rétention, archivage, et restauration), en plus de l'administration courante.
Alfresco est fragmenté, et nécessite un peu plus de préparation pour gérer les sauvegardes, en contrepartie, son support de MySQL m'assure une sauvegarde fonctionnelle immédiatement, et des archives que je sais restaurer sans lire le manuel. Alfresco bénéficie aussi d'un mécanisme de réplication, ce qui permet de bénéficier d'un second serveur de secours (ou de proximité) en cas de panne du serveur habituel.

Au bout du compte, j'ai l'impression que Nuxeo reste une solution intéressante. Ses points faibles ne sont pas si dramatiques, même si pour moi une bonne recherche par tags est primordiale. Alfresco propose des fonctionnalités appétissantes comme la réplication de serveur, une interface orientée utilisateur permettant la recherche par tags (Share). Mais le manque de glisser-déposer et glisser-déplacer, ainsi que le très grand nombre de clics pour la moindre action sont de vrais handicaps dans la phase de remplissage.
Malheureusement pour Nuxeo, je n'ai pas une minute à consacrer à l'apprentissage de PostgreSQL, ce qui laisse une chance à Alfresco de se faire une place sur mon serveur. Comme la migration d'un système à l'autre est totalement illusoire, voire impossible, je vais me laisser encore le temps de la réflexion, avant de charger et classer des centaines de documents dans l'un ou l'autre.

#!/bin/bash

################################################################################
# gestion du dump de la base de données
#
# nom de la DB
MA_DB=mabase
# dossier de travail :
MAISON=/var/root/svn
# nom et chemin du dépôt svn
NOM="backup_db"
REPOS="/var/subversion/${NOM}/trunk"
# répertoire de stockage du dump dans
# la copie de travail svn
MA_DB_DOCROOT=${MAISON}/${NOM}/${MA_DB}/
# nom du dump
DUMP_SQL=dump_${MA_DB}.sql
# login/mot de passe pour faire le dump
SQL_PASSWD=mon_pass
SQL_LOGIN=mon_log
# action : dump de la base MA_DB
cd /tmp/ || exit 1
/usr/bin/mysqldump -h localhost \
	--skip-dump-date \
	--skip-opt \
	--add-drop-table \
	--add-locks \
	--create-options \
	--disable-keys \
	--set-charset \
	-u ${SQL_LOGIN} -p${SQL_PASSWD} \
	--ignore-table=${MA_DB}.event_log ${MA_DB} > ${DUMP_SQL}

################################################################################
# gestion de l'enregistrement dans SVN
#
# chemin du binaire :
SVN=/usr/bin/svn

# umask de travail pour les documents sensibles :
umask='u=rwx,g=,o='

# si le dossier de destination n'existe pas on le crée :
[ ! -d $MAISON ] && umask $umask && mkdir $MAISON

# un peu d'environnement au cas où :
[ ! $HOME ] && HOME=/var/root

# on y va :
cd "$MAISON"
# si la copie de travail n'existe pas, on la crée.
# c'est "one shot".
if [ ! -d "${MAISON}/${NOM}" ]; then
	umask $umask
	mkdir "${MAISON}/${NOM}"
	echo "Checkout initial de ${NOM} !"
	$SVN co "file://${REPOS}" "${MAISON}/${NOM}"
fi
# on se place dans la copie de travail svn
cd "${NOM}"
umask $umask
# on l'update au cas où le dépôt svn aurait
# été mis à jour par un autre moyen
echo "Update de ${NOM}"
$SVN update
# copie conditionnelle du dump dans la copie de travail SVN
cd /tmp/
diff -q ${DUMP_SQL} ${MA_DB_DOCROOT}${DUMP_SQL} || \
	cp -f ${DUMP_SQL} ${MA_DB_DOCROOT}
# commit éventuel du dump de ${MA_DB}
$SVN commit -m "dump de ${MA_DB} du `date`" "${MA_DB_DOCROOT}${DUMP_SQL}"

Dans le détail, voici le déroulement du script :

1. Définition de variables.
2. Dump de la base de données $MA_DB dans le fichier /tmp/$DUMP_SQL.
3. Si le répertoire $MAISON n'existe pas, on le crée. Par défaut, c'est /var/root/svn, ce qui lui assure une certaine intimité mais oblige à lancer le script en root.
4. On se place dans $MAISON, et on crée le répertoire $NOM si il n'existe pas. Par défaut, c'est backup_db.
5. Si $NOM n'existait pas, c'est que le premier checkout du serveur SVN n'avait pas été fait, donc on le fait.
6. On se déplace dans $NOM, et on fait un update de la copie de travail.
7. Ensuite, si le dump /tmp/$DUMP_SQL est différent de celui qui est stocké dans la copie de travail ${MA_DB_DOCROOT}${DUMP_SQL} on replace ce dernier par le nouveau dump.
8. Pour finir on fait un commit du fichier de dump (si il n'a pas changé, le commit ne fait rien).

La partie du script qui effectue le dump de la base de données est importante, car le confort d'utilisation, et la taille du dépôt SVN en dépendent. Il convient notamment de faire bien attention à deux choses : chaque enregistrement dans la base doit avoir son propre INSERT dans le dump, et le fichier final ne doit pas contenir la date du dump.
Les INSERT groupés sont à éviter car ils forment des lignes excessivement longues, et que pour un seul caractère modifié dans une de ces lignes, SVN conserverait la ligne complète. En ayant un seul enregistrement par ligne on s'assure que les différences entre deux versions sont aussi petites et lisibles que possible, ce qui permet aussi de ralentir la prise de poids du dépôt SVN.
Si le fichier de dump contient sa propre date de création, on est alors sûr qu'il existera une différence entre le dump du jour et celui de la veille, même si rien ne change dans les données elles-même. Donc on aura un nouveau commit à chaque dump, sans savoir si il est vraiment significatif.
Un troisième point facultatif mais intéressant est la possibilité d'ignorer les tables qui changent beaucoup et qui ne sont pas significatives vis-à-vis de votre application. Dans le script ci-dessus, j'ai décidé d'ignorer la table nommée "event_log" : --ignore-table=${MA_DB}.event_log. Pour moi elle n'est pas du tout intéressante, et ferait gonfler artificiellement mon dépôt SVN tout en le remplissant de révisions non significatives.
À noter que ce script ne prend pas en charge la création du dépôt SVN, qui reste une tâche à la charge de l'administrateur. Il faut que le dépôt soit accessible localement (file://) par l'utilisateur qui lance le script de backup (ici root). D'autres combinaisons sont possibles, mais nécessitent des modifications assez importantes du script.

Une fois que tout cela fonctionne (via un automatisme comme cron, launchd, ...) il est très simple de restaurer une version arbitraire de la base de données. Il est aussi très facile de voir en une ligne de commande l'ensemble des différences entre deux versions du dump :

$ svn diff -rPREV dump_glpi.sql
Index: dump_glpi.sql
===================================================================
--- dump_glpi.sql	(revision 1774)
+++ dump_glpi.sql	(working copy)
@@ -9135,7 +9135,7 @@
 LOCK TABLES `glpi_users` WRITE;
 /*!40000 ALTER TABLE `glpi_users` DISABLE KEYS */;
 INSERT INTO `glpi_users` VALUES (2,'glpi0',...,'2009-07-15 10:44:57',...);
-INSERT INTO `glpi_users` VALUES (6,'user1',...,'2009-11-16 15:41:46'...,);
+INSERT INTO `glpi_users` VALUES (6,'user1',...,'2009-12-08 08:06:09'...,);
 INSERT INTO `glpi_users` VALUES (7,'user2',...,'2009-12-02 17:25:44'...,);
 INSERT INTO `glpi_users` VALUES (8,'user3',...,'0000-00-00 00:00:00'...,);
 INSERT INTO `glpi_users` VALUES (9,'user4',...,'0000-00-00 00:00:00'...,);

On a aussi l'assurance que les backups prennent bien moins de place que si on avait du tous les conserver intégralement.
Ainsi, j'ai une petite base de données (635 Ko), archivée dans subversion depuis juillet 2007 sous la forme de 443 révisions. Le poids total des révisions sur le serveur SVN est de 7,2 Mo, alors que le poids total d'une sauvegarde par jour pendant 900 jours représenterait environ 540 Mo. Même une excellente compression des dumps ne peut pas approcher le gain de place atteint par le stockage des modifications dans subversion.
Sur le long terme, et si votre base de données varie peu relativement à sa taille, la solution de l'archivage sous forme de révisions dans subversion est peut être la meilleure option. En tout cas, elle mérite qu'on s'y intéresse !

Le script que je propose ci-dessous doit être lancé en root, une fois par jour. Il fait une sauvegarde de chaque base de données qu'il trouve, et il conserve cette sauvegarde pendant 7 jours. En cas de pépin, il vous est donc possible de restaurer une ou plusieurs bases de données, en remontant de maximum 7 jours dans le passé.
Vous devez adapter absolument les lignes 2 à 5 pour indiquer les chemins suivants :

• mysqlroot : chemin du dossier contenant les bases de données sur le serveur
• monbkp : chemin du dossier contenant les sauvegardes des bases sur le serveur
• hotcopy : chemin de l'exécutable mysqlhotcopy sur le serveur
• mydump : chemin de l'exécutable mysqldump sur le serveur

Vous devez aussi remplacer LE_PASS_MYSQL par le mot de passe de root de MySQL. Attention, il n'y a pas d'espace entre -p et LE_PASS_MYSQL pour la commande mysqldump, mais il y a bien un espace entre le -p et LE_PASS_MYSQL pour la commande mysqlhotcopy.

Le script supporte un argument ("dump"). Si il est lancé avec cet argument, alors il utilisera mysqldump pour faire la sauvegarde. Vous obtenez alors un dump de chaque base, c'est à dire un fichier texte "plat" contenant les instructions SQL nécessaires à la reconstruction de la base de données. C'est la méthode que je recommande car le fichier obtenu peut être injecté dans presque n'importe quel serveur MySQL. Par ailleurs, le fichier obtenu est plus petit et plus facile à compresser.
Si le script est lancé sans l'argument "dump", alors la méthode de sauvegarde utilisée est mysqlhotcopy. Ce programme duplique physiquement le répertoire de chaque base de données. L'avantage c'est que la sauvegarde est prête à l'emploi, il n'est pas nécessaire de la ré-injecter dans le serveur. L'inconvénient, c'est qu'il vous sera probablement impossible d'utiliser cette sauvegarde sur un autre serveur que le votre, et dans la même version de MySQL. Si vous souhaitez archiver vos sauvegardes de bases de données et pouvoir les restaurer quelques mois ou années plus tard, il ne faut pas utiliser mysqlhotcopy.

Déroulement du script :

1. création d'un dossier temporaire /tmp/mysql
2. pour chaque base de données, création d'un dump ou d'une "hotcopy"
3. archivage et compression de chaque dump/hotcopy (en .tgz)
4. suppression de la version non-compressée
5. déplacement de la version compressée vers le dossier de sauvegarde
6. suppression du dossier temporaire /tmp/mysql

#!/bin/sh
mysqlroot=/var/db/mysql
monbkp=/backup/MYSQL
hotcopy=/usr/local/bin/mysqlhotcopy
mydump=/usr/local/bin/mysqldump

madate=`date "+%Y-%m-%d"`
monjour=`date "+%w"`

echo "lancement du backup des bases de donnees MySQL..."
echo

mkdir -m 0777 /tmp/mysql

cd $mysqlroot
for directory in *
do
if [ $directory != "" ]; then
if [ -d "$mysqlroot/$directory" ]; then
  echo -n "backup de $directory : "
  case $* in
    dump)
    $mydump -u root -pLE_PASS_MYSQL --opt $directory > "/tmp/mysql/$directory"
    ;;
    *)
    $hotcopy -u root -p LE_PASS_MYSQL -q "$directory" /tmp/mysql
    ;;
  esac
  if [ $? = 0 ]; then
    tar -czf "$monbkp/$madate$directory.tgz" -C /tmp/mysql/ "$directory"
    if [ $? = 0 ]; then
      rm -f "$monbkp/$directory.${monjour}.tgz"
      rm -r "/tmp/mysql/$directory"
      mv "$monbkp/$madate$directory.tgz" "$monbkp/$directory.${monjour}.tgz"
      echo "ok"
    else
      echo "Erreur targz".
    fi
  else
    echo "Erreur export".
  fi
fi
fi
done

rm -fR /tmp/mysql/

Pour lancer ce script toutes les nuits, j'utilise une crontab (car mon mysqld est installé sur un serveur FreeBSD). Le script est enregistré dans /usr/local/bin/ sous le nom BKP_SQL.sh. Voilà la ligne en question :

30 5 * * * /usr/local/bin/BKP_SQL.sh

Et si je souhaite faire des dumps plutôt que des "hotcopy" :

30 5 * * * /usr/local/bin/BKP_SQL.sh dump

 
Note : ce script n'est pas du tout une référence de fiabilité et encore moins d'élégance, néanmoins, je l'ai créé en 2003 et depuis il tourne tous les jours. Je n'ai jamais eu de problème avec.

Note 2 : selon le système, votre environnement, ... il vous faudra peut être indiquer le chemin complet pour l'application tar.

1) Si vous avez installé une ou plusieurs autres versions de MySQL et que vous souhaitez repartir de zéro, le plus simple est de localiser tous les éléments liés à MySQL et de les supprimer. On utilise pour cela la base locate, qu'il convient de mettre à jour au préalable :

sudo /usr/libexec/locate.updatedb
locate -i mysql

ensuite faites le tri dans ce que vous voyez, et supprimez les éléments appartenant aux anciennes installation de MySQL (sans doute dans /usr/local/, /Library/LaunchDaemon/, /Library/StartupItems/, ...)

2) Vérifiez votre PATH : les binaires de MySQL doivent se trouver dans votre PATH pour être exécutables sans indiquer leur chemin complet. Si la commande which mysql ne renvoie rien, ajoutez /usr/local/mysql/bin/ à votre PATH.

3) Vérifiez que le serveur mysqld est lancé (ps auxwww | grep mysqld) ou se lance bien (sudo /usr/local/mysql/bin/mysqld_safe).

4) Vérifiez que le socket du serveur existe quand il est lancé :

netstat -f unix | grep mysql
ls -l /tmp/mysql.sock

Si l'une de ces deux commandes ne retourne pas le chemin du socket, alors soit le socket est ouvert par le serveur mais supprimé par un autre process, soit le socket n'est pas ouvert par le serveur car il existe déjà.

5) Vérifiez que vous essayez bien d'accéder au serveur MySQL à partir d'un logiciel qui saura s'y connecter (php doit connaître le chemin du socket, le client mysql aussi). Si vous tentez une connexion réseau, vérifier aussi que mysqld ouvre un port réseau (netstat -alnf inet | grep 3306).

6) Jetez un œil aux fichiers de log de MySQL. Si le serveur ne se lance pas du tout, cela ne vous aidera probablement pas, mais si il se lance et quitte inopinément, ou si il se lance dans un état inutilisable, vous trouverez probablement des informations intéressantes dans ces fichiers. Pour l'installation de MySQL via le package officiel, les fichiers de log se trouvent normalement dans /usr/local/mysql/data/, sous le nom de localhost.err ou de votre-machine.err.

Je compléterai cette liste au fil du temps... N'hésitez pas à faire des suggestions !

Si vous aviez installé le script de démarrage de MySQL 5 mentionné dans le précédent article, il faudra le désactiver ou le supprimer. Pour le supprimer, vous pouvez exécuter les commandes suivantes dans le terminal :

sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop
sudo rm -r /Library/StartupItems/MySQLCOM
sudo rm /tmp/mysql.sock

Ensuite, vous pouvez créer le fichier /Library/LaunchDaemons/org.mysql.mysqld.plist avec votre éditeur favori, et coller dedans :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>org.mysql.mysqld</string>
	<key>OnDemand</key>
	<false/>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/mysql/bin/mysqld</string>
		<string>--socket=/tmp/mysql.sock</string>
		<string>--user=mysql</string>
		<string>--port=3306</string>
		<string>--datadir=/usr/local/mysql/data</string>
		<string>--pid-file=/usr/local/mysql/data/localhost.pid</string>
		<string>--bind-address=127.0.0.1</string>
	</array>
	<key>ServiceIPC</key>
	<false/>
</dict>
</plist>

Une fois que ce fichier est sauvé, il faut s'assurer qu'il appartient bien à root, sinon launchctl vous envoie sur les roses (cf. les commentaires de Pierre29). Dans le doute, exécutez la commande

sudo chown root /Library/LaunchDaemons/org.mysql.mysqld.plist

Vous pouvez ensuite activer ce plist par la commande

sudo launchctl load /Library/LaunchDaemons/org.mysql.mysqld.plist

MySQL devrait être alors lancé automatiquement pour vous. Il placera son socket dans /tmp/ et autorisera aussi les connexions TCP sur l'interface 127.0.0.1.

Je vous renvoie à la documentation de launchctl pour le reste des options et commandes disponibles et pour les détails sur l'utilisation de launchd. Votre serveur MySQL est désormais géré proprement par launchd, exactement comme sur un Mac OS X Serveur.

edit : ajout du chown root sur le fichier

La première étape pour une installation réussie, c'est de télécharger le package officiel fourni par MySQL. Ne cédez pas à la tentation de compiler vous même MySQL, si vous avez besoin d'aide pour installer un pkg, faites preuve de bon sens et oubliez immédiatement la compilation. On trouve le précieux paquet dans la zone "Developer" du site mysql.com. Cliquez sur "MySQL Community Server" dans la marge de gauche, et dans la nouvelle page qui se charge, trouvez le lien intitulé "Mac OS X (package format)". Je ne donne pas les liens directs, car ils sont susceptibles de changer au fil des versions de MySQL.
Vous voilà en face d'une liste de packages pour Mac OS X : Mac OS X (package format) downloads. Choisissez celui qui correspond le plus à votre version du système. Actuellement pour un G5 en Mac OS X 10.4 ou 10.5 ce sera "Mac OS X 10.4 (PowerPC, 64-bit)" par exemple.

Une fois l'image disque téléchargée et montée vous voici en face de deux packages, d'un "PrefPane", et d'un readme :

• mysql-5.0.45-osx10.4-powerpc-64bit.pkg (dans mon cas)
• MySQLStartupItem.pkg
• MySQL.prefPane
• ReadMe.txt

Le premier package installe tout MySQL sur votre machine. Le second installe un StartupItem à l'ancienne (comprendre : pré-launchd). Pour un lanceur à la mode de launchd : moderne et qui marche bien, voyez cet article. Le PrefPane permet d'installer un tableau de bord MySQL dans les préférences système.
Muni d'un log/pass d'administrateur vous pouvez maintenant installer les packages par simple double-click. Jusque là, pas besoin de comprendre la théorie de la relativité. Si vous avez su taper votre mot de passe, vous avez maintenant installé MySQL.
De la même manière, double-cliquez sur le PrefPane pour l'installer. Vous pouvez l'installer pour vous uniquement, ou pour tous les utilisateurs de la machine. C'est sans incidence sur le résultat, faites comme vous préférez. Ce tableau de bord est de toute manière partiellement non-fonctionnel sous Leopard (je ne l'ai pas testé sous Tiger). Il ne permet pas de lancer ou d'arrêter MySQL via le bouton de son interface. Par contre, il permet d'activer ou non le lancement automatique du serveur MySQL au démarrage de la machine.
À partir de là, votre serveur MySQL est complètement fonctionnel. Si vous avez opté pour un lancement automatique au démarrage, vous pouvez maintenant rebooter pour vérifier que cela fonctionne, tout en vous félicitant d'avoir installé MySQL 5 en moins de 5 minutes, sans taper une seule ligne de commande dans votre terminal. Si vous souhaitez lancer le serveur sans redémarrer et que, comme dans mon cas, le bouton ad hoc du tableau de bord de fonctionne pas, vous pouvez le faire via le terminal :

• cochez la case pour lancer MySQL automatiquement au démarrage (cela édite pour vous un fichier de configuration qui autorise aussi le lancement manuel)
• tapez dans une fenêtre de terminal la commande
  sudo /Library/StartupItems/MySQLCOM/MySQLCOM start

Normalement, le tableau de bord doit maintenant refléter l'état du serveur, et indiquer que le serveur est fonctionnel. Si ce n'est pas le cas, c'est que vous êtes parvenu à rater une des étapes précédentes.

Désormais, il est judicieux de tester la connexion au serveur. Ouvrez une fenêtre de terminal, et taper la commande suivante :

/usr/local/mysql/bin/mysql -u root

Cela doit vous donner le résultat suivant :

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 200
Server version: 5.0.45 MySQL Community Server (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> 

Vous êtes alors connecté à votre serveur mysql local. Il est important de noter que les packages officiels de MySQL sont compilés pour stocker le socket de connexion dans /tmp/mysql.sock, et non pas dans /var/mysql/mysql.sock. Le PHP fourni par Apple quant à lui, attend ce socket dans /var/mysql/mysql.sock. Si vous souhaitez faire fonctionner des scripts PHP, vous devrez indiquer à ce dernier le chemin réel de votre socket MySQL. On fait cela en éditant le fichier /private/etc/php.ini. Ouvrez ce fichier (probablement inexistant) avec votre éditeur de texte favori, et insérez la ligne mysql.default_socket = /tmp/mysql.sock. Maintenant, PHP doit trouver tout seul le socket de MySQL. C'est facile à vérifier dans le terminal :

php -r 'mysql_connect(localhost, root, ""); echo mysql_result(mysql_query("SELECT 2+2;"),0)." ";'

Si tout fonctionne, le résultat affiché sera "4". Si cela ne fonctionne pas, c'est probablement que vous êtes incapable d'utiliser MySQL de toute manière :).

edit : en cas de pépin, faites un tour vers la checklist.

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.