Bonjour,
Je fais suite à la demande de Fil en vous faisant ici un retour d'expérience
sur le site http://www.humanite.fr
Rapidement quelques chiffres :
- 2003 http://www.humanite.fr passe sous spip
- 3 juillet 2007, relookage graphique et SQL
- 380 000 articles (intégralité des éditions de 1990 à nos jours)
- 73 mots clefs
- 5 600 rubriques
- 3 240 documents
- 1 800 000 visites/mois
- 3 000 000 pages vues/mois
- 3 serveurs (Apache, MySQL, Intuition)
- 5 personnes qui bossent dessus côté contenu
- 2 développeurs/intégrateurs
- 1 graphiste
- 1 administrateur système
Spécificité non spip du site de l'huma :
- Intuition, moteur de recherche sémantique de Sinequa, on fait un export de
la base spip_articles sous forme XML qu'on indexe dans intuition (voir
http://www.humanite.fr/recherche.html )
- Import XML tous les jours les éditions arrivent sous forme de XML sur le
serveur en scp. Une moulinette perl les traite les analyses et les insère
dans spip_articles.
- Une page d'admin spécifique qui permet d'attribuer des mots clefs aux 75
articles quotidiens sur un seul formulaire, et de publier tous les articles
en un seul clic.
Spécificité spip :
- pas de moteur de recherche
- pas de statistiques
- pas de suivi des revisions
Ajout et modif pour l'huma, qui ne sont pas de plugins car trop spécifiques,
(nous n'avons jamais touché au coeur et nous faisons des plugins pour etendre
la couverture fonctionnelle ) :
- a partir des urls_propres creation des urls_huma comprenant rubrique
mots_clefs et url_article (on a du s'appuyer sur un vieux dev fait sous spip
1.4 ), creation de 2 balises : #URL_GROUPES_MOTS et #URL_RUBRIQUE_MOT. Ceci
inclus une quantité importante de rêgle de rewriting pour rester compatible
avec les anciennes URLs.
- page abonnement
- envoyer cet article
Pour que tout se passe bien nous avons fait des optis sur les différents
serveurs :
- Apache est optimisé loin de ses confs par défaut, AllowOverride None,
Rewrite rule dans la conf serveur entre autres. Il y aurait un cours d'opti
apache complet à faire la dessus.
- Mysql est pas mal tuné pour s'adapter à la base, le repertoire de cache
mysql est en tmpfs.
- le /tmp de spip est un tmpfs de 4Go
Aujourd'hui tout se passe bien, le site encaisse les indexations furieuses et
concurrentes de Slurp et de Googlebot.
Mais, car il y a un malheureusement un mais, le cron_invalideur lance des
requêtes épouvantables toutes les heures...
Genre :
UPDATE `humav3`.spip_caches SET type='x' WHERE ((fichier IN
('5/_%2B%3Fdebut_art%3D415.135a013c', '0/c-mot_rubrique_contenu.8fca39cb', 'a/cor-846221-12806-id-fr.2caceb4c', ....
sur des centaines de lignes.
Je pense qu'elle vient de la ligne 106 dans ecrire/inc/invalideur.php
spip_query("UPDATE spip_caches SET type='x' WHERE " .
calcul_mysql_in('fichier', $tous));
La requête prends entre 40 et 70 secondes (j'ai une moyenne de 300 000
fichier dans spip_caches).
Mettre le tmp de spip dans un tmpfs peut sembler critiquable. Je l'ai fait
pour plusieurs raisons :
- je disposais de la RAM pour le faire.
- tmpfs est super rapide en écriture.
- tmpfs est super rapide en suppression de fichier, et lors de l'effacement
horaire de la cache quand je suis sur mon systeme de fichier ext3 (Raid 10
scsi 15k) le load s'envole à coup de rm (je précise que dans ce cas
$quota_cache=0).
Enfin le calcul du quota de la cache est faux, mais c'est semble-t'il lié a
php qui ne peut pas prendre en compte la taille occupée sur le disque plutôt
que la taille des données, du coup comme la taille des blocs de mon système
de fichier est de 512, l'erreur que fait spip pour le dimensionnement de son
cache est de +60%. Quand on le sait ce n'est pas grave mais au début cela
surprend 
Merci à tous,
VIVE SPIP !
PS: si vous voulez des précisions sur un point n'hésitez pas à le demander.
mais qui laisse plus d'erreur.