Questions sur le premier problème : y a t-il des pièges ou bien des
risques particuliers ? Le schéma de la base de données de Spip ne
contient pas de contraintes d'intégrité (parce que MySQL ne sait pas
faire ?)
Oui je pense que cela vient de là .
Par exemple, on peut injecter un article avec un statut nul
alors que Spip ne sait pas les traiter. C'est par essai/erreur que
j'ai découvert les contraintes à respecter.
C'est le problème de MySQL. En revanche, on est censés
pas mal gagner en performances grace à cela.
Deuxième problème : une fois tout injecté, ça rame. Horriblement. Bien
sûr, la machine de test est peu rapide mais je suis pour l'instant le
seul lecteur. Donc, faut optimiser.
et la page ci-dessus ne
contiennent guère d'indication pour ce problème des gros
sites. Notamment, rien sur l'optimisation de la base de données, les
index recommandés, etc. Un profilage sommaire indique que c'est MySQL
qui nous bloque. Je lis
, je vais
faire quelques EXPLAIN mais, avant de me lancer, je voudrais savoir qi
quelqu'un l'a déjà fait et écrit le "SPIP Optimisation HOWTO" ?
Dans mon expérience de Spip, le seul problème que j'ai
eu concernait l'existence de code php non mis en cache,
problème résolu par un petit bout de scotch le forçant Ã
mettre en cache le résultat sur certains squelettes.
Je pense que les techniques standard de BDD doivent
s'appliquer à votre problème. Vérifier l'indexation des
clés primaires et étrangères... les types d'indexes...
Les Explain plan devraient vous aider.
Je serais ravi que vous communiquiez sur la liste le
résultat de vos recherches. Je travaille actuellement sur
un site spip amené à recevoir pas mal de contenu et de
charge, je serais ravi de vous donner un coup de main sur
des recherches complémentaires.
Question : qu'est-ce qui rame exactement ? Est-ce
l'affichage d'articles triés par date par example ?
L'accès à un seul article ? Il peut être intéressant de
se poser la question du tri, reliée à celle des indexes.
Ensuite, le test peut consister à examiner les temps
de réponse d'un requête SQL en "direct" sur la base, et de
les comparer à ce que prend SPIP. Sur une requête TRES
utilisée, on peut alors être amené à modifier SPIP, voire
à faire une requête spécifique (je sais, c'est politiquement incorrect, mais bon 
Question supplémentaire sur le deuxième problème : j'injecte tout dans
une seule rubrique. Ai-je intérêt, pour ce qui concerne les
performances, Ã injecter dans N rubriques ? Ca ne changera pas la
table spip_articles mais cela peut changer la façon dont Spip accès
aux articles.
Au sens base de données, je ne pense pas. Voyez plutôt
les tris et le nombre d'enregistrement pris en compte pour
le (plus petit) nombre d'entre eux affiché.
Bien cordialement.
Gregory Fabre