[spip-dev] Re[3]: [Spip] Optimisation de SPIP pour un site à très gros trafic

Dev
1

Et si on passait sur spip-dev ? :wink:

Pour info, MySQL commence à peiner en mode stressé à partir de 10
millions d'enregistrements, environ.

Envion 40 forums avec 5000 messages postés chaque jour pendant
plusieurs mois.

5000 messages par forum, ou en tout ???

Si c'est en tout, ça fait 150000 messages par mois, à raison d'un
message toutes les 8 secondes (journées de 12h), donc MySQL peut tenir
sans problème la charge pendant des années. Il lui faudra 5 ans pour
atteindre les 10 millions de lignes, mais il n'est pas en mode
stressé, donc il peut tenir encore longtemps.

Si c'est par forum, ça change tout, ça fait 6 millions de messages par
mois, à raison de 10 messages par seconde. C'est pas encore du méchant
stress, mais la volumétrie risque de vite exploser. Il faudrait donc
gérer une table par forum, pour revenir dans l'autre situation.

On ne peut pas trop prévoir, il faudrait tester. En tout cas, avec
une telle quantité de données, tu as intérêt à avoir beaucoup de RAM
(plusieurs Go ?)

Pourquoi ???

et si possible des disques rapides (en RAID par exemple).

Euh ... c'est pas parce que c'est en RAID que c'est plus rapide, à un
poil de schtroumph près, c'est même plus lent ...

Ce qui est sûr, c'est que l'interface de modération dans l'espace
privé ne sera pas à la hauteur.

Là, c'est clair ... :wink:

3) Quelqun a-t-il déjà utilisé plusieurs frontaux SPIP +
   réplication MySQL ?

-Nicolas

2

Si c'est en tout, ça fait 150000 messages par mois, à raison d'un
message toutes les 8 secondes (journées de 12h), donc MySQL peut tenir
sans problème la charge pendant des années. Il lui faudra 5 ans pour
atteindre les 10 millions de lignes, mais il n'est pas en mode
stressé, donc il peut tenir encore longtemps.

Si c'est par forum, ça change tout, ça fait 6 millions de messages par
mois, à raison de 10 messages par seconde. C'est pas encore du méchant
stress, mais la volumétrie risque de vite exploser. Il faudrait donc
gérer une table par forum, pour revenir dans l'autre situation.

On ne peut pas trop prévoir, il faudrait tester. En tout cas, avec une
telle quantité de données, tu as intérêt à avoir beaucoup de RAM
(plusieurs Go ?)

Pourquoi ???

Parce que le problème sera le même que celui de Stéphane et de ses 180 000
articles. Du fait de la taille du fichier de données engendré, et comme
à peu près toutes les requêtes n'utilisent pas que l'index pour sélectionner
le résultat (par exemple, tu prends les dix derniers messages de l'article,
c'est-à-dire que tu scannes tous les messages de l'article pour trier
par date et ensuite seulement garder les dix derniers), si la table ne
tient pas en RAM les mouvements de la tête de lecture vont ruiner les
performances.

Tu as vu les résultats de Stéphane : quelques secondes pour compter quelques
milliers d'articles uniquement sur l'index ; quelques minutes pour le même
jeu d'articles, mais en vérifiant en plus que statut='publie' (nécessité
de lire les données). Pour moi la seule interprétation de ce comportement,
c'est que la lecture des données dans le second cas, qui sont disséminées
partout dans le gros fichier de plusieurs Go, sollicite énormément le
disque dur. Et pourtant les données lues, en soi, ne sont pas grosses
(quelques milliers de champs statut (varchar(10)).

Euh ... c'est pas parce que c'est en RAID que c'est plus rapide, à un
poil de schtroumph près, c'est même plus lent ...

Je sais pas trop, mais je pense quand même que du RAID 5 matériel sur
du SCSI, ça accélère pas mal les performances (surtout si la carte RAID
a un bon gros cache). Ceci dit, ça sort un peu de mes compétences.

a+

Antoine.

3

tu as intérêt à avoir beaucoup de RAM (plusieurs Go ?)

Pourquoi ???

Parce que le problème sera le même que celui de Stéphane [...]
si la table ne tient pas en RAM les mouvements de la tête de lecture
vont ruiner les performances.

Ah oui, pas pensé à ça ... :wink:

Euh ... c'est pas parce que c'est en RAID que c'est plus rapide, à
un poil de schtroumph près, c'est même plus lent ...

Je sais pas trop, mais je pense quand même que du RAID 5 matériel
sur du SCSI, ça accélère pas mal les performances (surtout si la
carte RAID a un bon gros cache).

Bin le cache de la carte RAID, c'est justement pour éviter de perdre
ce poil de schtroumph dont je parlais, parce que sinon, une batterie
de disques en RAID 5 ne peut pas être plus rapide qu'un disque seul,
c'est physique, mais ce sera par contre beaucoup plus costaud ... :wink:

Ceci dit, ça sort un peu de mes compétences.

Je ne suis pas expert non plus, note. :smiley:

-Nicolas

4

Bin le cache de la carte RAID, c'est justement pour éviter de perdre ce
poil de schtroumph dont je parlais, parce que sinon, une batterie de
disques en RAID 5 ne peut pas être plus rapide qu'un disque seul, c'est
physique, mais ce sera par contre beaucoup plus costaud ... :wink:

Heu, comment ça ? Si tous les disques vont chercher des données à la fois,
le débit résultant est N fois celui d'un seul disque (ou N - 1 car un disque
sert à la redondance).

5

Oui... faut pas confondre RAID5 et mirroir (raid1)

En miroir, tu copies sur un disque, et tu copies sur l'autre.
En raid 5 à 3 disques, si c'est une carte raid (mylex par exemple voire
adpatec), tu envoies le paquet à la carte, qui code le CRC et envoie en
simultané sur les 3 disques.
Ca va donc 2 fois plus vite pour tout écrire, + le chouia de calcul des
CRC.

En RAID5 5 disques, ça va 4 fois plus vite, plus le chouia de calcul du
CRC.

Et en lecture, tu t'occupes même pas du CRC.