[spip-dev] [AlwaysData] Impact de SPIP sur les I/O disque selon un hébergeur

Dev
1

Bonjour,

L’hébergeur AlwaysData, chez qui j’ai trois sites SPIP 3 à faible trafic (et avec le système de cache par défaut), m’a envoyé ce message :

------------------8<---------------------------------------------------------------------------------------
Bonjour,

Nous constatons que votre compte est un gros consommateur d’écritures disque. Cela a un impact important sur nos serveurs : moins d’une dizaine de comptes consomment plus de 95 % des ressources sur un serveur donné. D’où parfois des ralentissements.

Bien entendu, dans l’immense majorité des cas, les clients les plus consommateurs n’en ont pas conscience. Certaines applications sont notamment connues pour être voraces — SPIP, par exemple. Globalement, tout système de cache/sessions/base de données basé sur le système de fichiers va générer de nombreuses écritures.

Afin d’améliorer la situation pour l’ensemble de nos clients, nous avons déployé en beta une technologie qui réduit l’impact des écritures (en combinant un SSD et un disque mécanique). Un seul de nos serveurs est pour le moment équipé de cette technologie, afin d’étudier ses résultats et, s’ils s’avèrent concluants, de la généraliser à l’ensemble de nos serveurs.

Nous allons migrer l’ensemble des comptes consommateurs —dont le vôtre — sur ce nouveau serveur. La technologie étant encore considérée comme beta, il y a un risque non nul, bien que faible, pour que des problèmes inattendus surviennent. Nous avons évidemment redoublé de vigilance, notamment en ajoutant un système supplémentaire de sauvegardes effectué chaque heure, pour pallier les éventualités les plus graves.

Si vous souhaitiez que votre compte ne soit pas migré, il vous faudrait arrêter la surcharge en écritures. Dans le cas contraire, votre compte sera migré dans les prochains jours.

J’ajoute que votre compte est le premier à pâtir de ces écritures fréquentes. En conséquence, si la technologie tient ses promesses, cela peut améliorer sensiblement les performances de votre compte. Dans certains cas, de manière spectaculaire.

Cordialement,

------------------8<---------------------------------------------------------------------------------------

Il a ajouté ceci un peu après :

------------------8<---------------------------------------------------------------------------------------

Je connais trop mal SPIP pour le juger de manière générale. En revanche, en tant qu’administrateur système, c’est une plaie à cause de sa consommation d’IO ; c’est affolant.

------------------8<---------------------------------------------------------------------------------------

Je ne transmets pas cela pour troller, juste pour informer, et éventuellement permettre aux personnes compétentes d’apporter une réponse constructive.

2

Réponse très constructive ici : http://plugins.spip.net/memoization.html
… qui permet d’employer, au choix, memcache, xcache, etc

3

Bonjour,

L’hébergeur AlwaysData, chez qui j’ai trois sites SPIP 3 à faible trafic (et avec le système de cache par défaut), m’a envoyé ce message :

------------------8<---------------------------------------------------------------------------------------
Bonjour,

Nous constatons que votre compte est un gros consommateur d’écritures disque.

Une grosse consommation en écriture disque traduit un dysfonctionnement du site, ou une erreur dans l’écriture des squelettes ou d’un plugin (cache très court, URLs en boucle infinie parsée par des robots qui génèrent un volume infini de cache, écriture en base de données à chaque hit…).

Après on peut amoindrir le problème en recourant déplaçant le cache en mémoire via memoization et/ou l’utilisation de dev/shm. Mais c’est une optimisation, il faut résoudre le défaut initial à la base.

------------------8<---------------------------------------------------------------------------------------

Je connais trop mal SPIP pour le juger de manière générale. En revanche, en tant qu’administrateur système, c’est une plaie à cause de sa consommation d’IO ; c’est affolant.

Tu devines ce que je vais dire :p.
Mais sans rire, c’est un peu le problème général des hébergeurs qui ne connaissent pas l’applicatif hébergé et sont dans l’impossibilité d’optimiser leur configuration, sauf à faire des choses très génériques.
Oui un SSD ça va très vite et c’est génial, mais un site SPIP n’a aucune raison d’engorger le système disque en écriture. SPIP-Contrib tourne sur un petit serveur bas de gamme avec un sous-système disque assez peu véloce, sans problème.

Cédric

4

Beaucoup de #SESSION dans des inclures différents au sein d'une même page
par exemple aussi non?

/me cherche des exemples car cela m'arrive également de faire monter le
load sur une machine même si j'ai des crins gourmands comme salvatore par
exemple sur celle en question

J'ai également un beau soucis lors du passage de Bing de temps en temps

kent1

PS: J'ai aussi un gros problème d'inattention à ne pas cliquer sur reply
all (désolé Cédric, deux fois dans la même journée)

5

Je veux bien creuser…

A priori non.

A priori non, je surveille un peu Google Webmaster Tools.

J’ai désactivé les stats, donc à priori non.

Aucune balise #SESSION chez moi.

Ah, j’ai vu que bingbot et msnbot passent pas mal souvent…

6

Je suis administrateur système chez alwaysdata, je me permets de participer à la discussion pour apporter mon point de vue.

Je précise que je n'ai pas d'expérience directe avec SPIP (i.e. je n'en ai jamais installé/configuré un) ; je ne vois les choses que via le prisme du sysadmin.

Une grosse consommation en écriture disque traduit un dysfonctionnement
du site, ou une erreur dans l'écriture des squelettes ou d'un plugin
(cache très court, URLs en boucle infinie parsée par des robots qui
génèrent un volume infini de cache, écriture en base de données à chaque
hit...).

Les fichiers fréquemment modifiés que j'observe sur la plupart des SPIP que j'héberge, ce sont ceux du répertoire 'tmp' : essentiellement logs, cache et sessions.

Étant donné que ces mêmes fichiers reviennent inlassablement à travers des installations de SPIP faites par des individus différents, j'ai supposé que par défaut, une installation SPIP écrivait dans ces fichiers, et ce sans avoir un trafic important.

Après on peut amoindrir le problème en recourant déplaçant le cache en
mémoire via memoization et/ou l'utilisation de dev/shm. Mais c'est une
optimisation, il faut résoudre le défaut initial à la base.

95% des gens vont garder la configuration par défaut. De mon point de vue, c'est donc ce qui compte, et ce qui me permet d'observer que SPIP est particulièrement consommateur d'IO en général.

Je ne doute pas qu'il est possible d'optimiser SPIP pour qu'il tape moins (voire pas) sur le disque.

Je connais trop mal SPIP pour le juger de manière générale. En
revanche, en tant qu'administrateur système, c'est une plaie à cause
de sa consommation d'IO ; c'est affolant.

Tu devines ce que je vais dire :p.
Mais sans rire, c'est un peu le problème général des hébergeurs qui ne
connaissent pas l'applicatif hébergé et sont dans l'impossibilité
d'optimiser leur configuration, sauf à faire des choses très génériques.

C'est en effet le principe de l'hébergeur mutualisé généraliste, comparé à un hébergeur dédié (ce qu'on fait aussi, au passage) ou à un hébergeur mutualisé spécialisé (e.g. wordpress.com).

Oui un SSD ça va très vite et c'est génial, mais un site SPIP n'a aucune
raison d'engorger le système disque en écriture. SPIP-Contrib tourne sur
un petit serveur bas de gamme avec un sous-système disque assez peu
véloce, sans problème.

Je ne suis pas sûr qu'on ait la même définition d'engorgement. Partons du principe qu'un disque mécanique classique encaisse 100 IOPS, et qu'un site SPIP consomme 5 IOPS par défaut.

Effectivement, ça tiendra très largement sur n'importe quel serveur bas de gamme, avec une grosse marge même (5 % de consommation seulement).

Maintenant, plaçons-nous du point de vue d'un hébergeur mutualisé. Avec 5 IOPS, je fais tenir 20 sites SPIP (en partant du principe qu'on accepte d'aller jusqu'à une consommation IO de 100 %, ce qui est évidemment une grossière approximation).

20 clients par serveur, c'est pas tenable financièrement pour du mutualisé (ou alors je dois augmenter sensiblement mes tarifs, et les clients iront voir ailleurs).

Autre manière de voir les choses : comparer les applicatifs entre eux. Si j'ai un SPIP à 5 IOPS et un WordPress (par exemple) à 0,1 IOPS en moyenne, alors j'en déduis qu'en moyenne, par défaut, SPIP est très vorace en IO.

Mon discours n'est pas de pointer du doigt SPIP, encore moins d'accuser. Je partage juste mes observations en tant qu'hébergeur mutualisé :slight_smile:

7

------------------8<---------------------------------------------------------------------------------------

Je connais trop mal SPIP pour le juger de manière générale. En revanche, en tant qu’administrateur système, c’est une plaie à cause de sa consommation d’IO ; c’est affolant.

Tu devines ce que je vais dire :p.

Oui, bien sûr, ce n’est pas la première fois que le sujet arrive ici… :wink:

Mais sans rire, c’est un peu le problème général des hébergeurs qui ne connaissent pas l’applicatif hébergé et sont dans l’impossibilité d’optimiser leur configuration, sauf à faire des choses très génériques.

D’où l’idée de les aider. Peut-être cette discussion permettra-t-elle de pondre un article de doc qui leur soit destiné.

Oui un SSD ça va très vite et c’est génial, mais un site SPIP n’a aucune raison d’engorger le système disque en écriture. SPIP-Contrib tourne sur un petit serveur bas de gamme avec un sous-système disque assez peu véloce, sans problème.

Avec Memoization ?

8

Je suis administrateur système chez alwaysdata, je me permets de participer à la discussion pour apporter mon point de vue.

Je précise que je n'ai pas d'expérience directe avec SPIP (i.e. je n'en ai jamais installé/configuré un) ; je ne vois les choses que via le prisme du sysadmin.

Une grosse consommation en écriture disque traduit un dysfonctionnement
du site, ou une erreur dans l'écriture des squelettes ou d'un plugin
(cache très court, URLs en boucle infinie parsée par des robots qui
génèrent un volume infini de cache, écriture en base de données à chaque
hit...).

Les fichiers fréquemment modifiés que j'observe sur la plupart des SPIP que j'héberge, ce sont ceux du répertoire 'tmp' : essentiellement logs, cache et sessions.

Les sessions ne sont normalement remises à jour que pour des visiteurs identifiés, donc pour les admins qui utilisent le back-office
Les logs sont par défaut non verbeux sous SPIP 3, on a beaucoup réduit le débit en écriture dans les fichiers de logs de ce fait. Mais en pratique, chaque fois que j'ai essayé de désactiver les logs, je n'ai pas constaté d'effet notable.

Reste donc le cache, et c'est en général là le noeud du problème, et j'en reviens aux possibilités évoquées ci-dessus.

Étant donné que ces mêmes fichiers reviennent inlassablement à travers des installations de SPIP faites par des individus différents, j'ai supposé que par défaut, une installation SPIP écrivait dans ces fichiers, et ce sans avoir un trafic important.

Tout à fait. Et pour être très clair, SPIP est conçu par nature pour absorber des pics de trafic sans solliciter le gestionnaire SQL. Sur un site à très petit trafic, il est possible que l'écriture d'un cache ne soit pas rentable, car jamais réutilisé (une seule personne a visité le site pendant la validité du cache).

L'autre source évidente de ce point de vue concerne les robots d'indexation qui parcourent toutes les pages du site, une fois, et génèrent de l'écriture en cache a priori vaine.

Après on peut amoindrir le problème en recourant déplaçant le cache en
mémoire via memoization et/ou l'utilisation de dev/shm. Mais c'est une
optimisation, il faut résoudre le défaut initial à la base.

95% des gens vont garder la configuration par défaut. De mon point de vue, c'est donc ce qui compte, et ce qui me permet d'observer que SPIP est particulièrement consommateur d'IO en général.

Oui, mais là encore, quelle configuration par défaut pour quel profil de site ?...

Je ne doute pas qu'il est possible d'optimiser SPIP pour qu'il tape moins (voire pas) sur le disque.

Je connais trop mal SPIP pour le juger de manière générale. En
revanche, en tant qu'administrateur système, c'est une plaie à cause
de sa consommation d'IO ; c'est affolant.

Tu devines ce que je vais dire :p.
Mais sans rire, c'est un peu le problème général des hébergeurs qui ne
connaissent pas l'applicatif hébergé et sont dans l'impossibilité
d'optimiser leur configuration, sauf à faire des choses très génériques.

C'est en effet le principe de l'hébergeur mutualisé généraliste, comparé à un hébergeur dédié (ce qu'on fait aussi, au passage) ou à un hébergeur mutualisé spécialisé (e.g. wordpress.com).

Oui un SSD ça va très vite et c'est génial, mais un site SPIP n'a aucune
raison d'engorger le système disque en écriture. SPIP-Contrib tourne sur
un petit serveur bas de gamme avec un sous-système disque assez peu
véloce, sans problème.

Je ne suis pas sûr qu'on ait la même définition d'engorgement. Partons du principe qu'un disque mécanique classique encaisse 100 IOPS, et qu'un site SPIP consomme 5 IOPS par défaut.

Effectivement, ça tiendra très largement sur n'importe quel serveur bas de gamme, avec une grosse marge même (5 % de consommation seulement).

Maintenant, plaçons-nous du point de vue d'un hébergeur mutualisé. Avec 5 IOPS, je fais tenir 20 sites SPIP (en partant du principe qu'on accepte d'aller jusqu'à une consommation IO de 100 %, ce qui est évidemment une grossière approximation).

20 clients par serveur, c'est pas tenable financièrement pour du mutualisé (ou alors je dois augmenter sensiblement mes tarifs, et les clients iront voir ailleurs).

Autre manière de voir les choses : comparer les applicatifs entre eux. Si j'ai un SPIP à 5 IOPS et un WordPress (par exemple) à 0,1 IOPS en moyenne, alors j'en déduis qu'en moyenne, par défaut, SPIP est très vorace en IO.

Mon discours n'est pas de pointer du doigt SPIP, encore moins d'accuser. Je partage juste mes observations en tant qu'hébergeur mutualisé :slight_smile:

Je veux bien croire que les outils ont des profils de consommation de ressource différents selon le trafic du site.

Cédric

9

Cédric Morin wrote:

Reste donc le cache, et c'est en général là le noeud du problème, et
j'en reviens aux possibilités évoquées ci-dessus.

Le cache représente en effet la plus grosse source de consommation d'IO.

Étant donné que ces mêmes fichiers reviennent inlassablement à
travers des installations de SPIP faites par des individus
différents, j'ai supposé que par défaut, une installation SPIP
écrivait dans ces fichiers, et ce sans avoir un trafic
important.

Tout à fait. Et pour être très clair, SPIP est conçu par nature pour
absorber des pics de trafic sans solliciter le gestionnaire SQL. Sur
un site à très petit trafic, il est possible que l'écriture d'un
cache ne soit pas rentable, car jamais réutilisé (une seule personne
a visité le site pendant la validité du cache).

En ce qui me concerne, je préfère largement qu'un client aille taper dans MySQL plutôt que dans le disque. Pourquoi ? Parce qu'un disque, c'est lent, et une écriture n'est pas cachable. À l'inverse, une lecture, ça se cache très bien (en RAM), donc est accessible ultra rapidement.

Il m'arrive donc de conseiller à des clients de désactiver leur cache disque pour *augmenter* les performances parce que l'IO est saturé, et que les écritures peuvent parfois prendre jusqu'à plusieurs secondes.

Et de toute façon, à moins que la base soit mal foutue et/ou énorme, une requête SQL est normalement extrêmement rapide.

10

Cédric Morin wrote:

Reste donc le cache, et c'est en général là le noeud du problème, et
j'en reviens aux possibilités évoquées ci-dessus.

Le cache représente en effet la plus grosse source de consommation d'IO.

Étant donné que ces mêmes fichiers reviennent inlassablement à
travers des installations de SPIP faites par des individus
différents, j'ai supposé que par défaut, une installation SPIP
écrivait dans ces fichiers, et ce sans avoir un trafic
important.

Tout à fait. Et pour être très clair, SPIP est conçu par nature pour
absorber des pics de trafic sans solliciter le gestionnaire SQL. Sur
un site à très petit trafic, il est possible que l'écriture d'un
cache ne soit pas rentable, car jamais réutilisé (une seule personne
a visité le site pendant la validité du cache).

En ce qui me concerne, je préfère largement qu'un client aille taper dans MySQL plutôt que dans le disque. Pourquoi ? Parce qu'un disque, c'est lent, et une écriture n'est pas cachable. À l'inverse, une lecture, ça se cache très bien (en RAM), donc est accessible ultra rapidement.

Oui bien sur. Le but du cache est pas non plus d'écrire à chaque hit sur le disque :wink:
Mais comme tout cache, il est est conçu avec certaines hypothèses d'utilisation, et on peut donc ne pas être dans le scenario ou il fait gagner du temps.

Il m'arrive donc de conseiller à des clients de désactiver leur cache disque pour *augmenter* les performances parce que l'IO est saturé, et que les écritures peuvent parfois prendre jusqu'à plusieurs secondes.

Et de toute façon, à moins que la base soit mal foutue et/ou énorme, une requête SQL est normalement extrêmement rapide.

L'ordre de grandeur c'est plutôt 200 requêtes SQL par hit si on n'a pas de cache.
Il est facile de faire un test de desactivation du cache, ce qui fonctionnera peut-être mieux dans le cas usuel (mais ne protège plus le serveur SQL en cas de pic de traffic sur une page).
Cela dit il serait intéressant de voir un peu plus finement si par exemple ce ne seraient pas les bots d'indexation qui génèrent la majeur partie de la charge et si ce n'est pas juste pour eux qu'il faudrait désactiver le cache (puisque on sait que eux ne joueront jamais tout d'un coup des centaines de hits par seconde sur une page)

Cédric

11

Cela dit il serait intéressant de voir un peu plus finement si par exemple
ce ne seraient pas les bots d'indexation qui génèrent la majeur partie de
la charge et si ce n'est pas juste pour eux qu'il faudrait désactiver le
cache

il est assez facile (et intéressant) de profiler tout ça, mais ce qui est
compliqué, c'est de savoir ce que l'on veut (exemple : favoriser les
lectures SQL ou celles du disque). Donc de fait c'est la configuration de
ceux qui passent leur vie dans les logs qui finit par s'imposer à tous.

Comme chez moi MySQL a toujours semblé être le facteur fragile, je n'ai
jamais imaginé l'utiliser comme… outil de cache… mais il pourrait être
intéressant de créer un module "sql" pour mémoization. Cela dit memcache,
xcache ou APC sont largement préférable *dans mes tests*.

A ne pas oublier tout de même : le temps de calcul d'une page ne se limite
pas au temps de lecture des données dans la base, il y a aussi tous les
calculs de la fonction propre() etc. De ce point de vue, désactiver
totalement le cache ne paraît pas une super idée.

-- Fil

12

Cédric Morin wrote:

L'ordre de grandeur c'est plutôt 200 requêtes SQL par hit si on n'a pas de cache.

200 requêtes pour une page simple, ça parait sacrément élevé, mais c'est un autre sujet.

À supposer que ce soient des requêtes simples (avec index, etc.), on peut tabler sur moins d'une milliseconde par requête, soit 200 ms. Ce qui n'est pas énorme.

À comparer avec une latence qui peut dépasser la seconde pour une écriture disque quand l'IO est surchargé... d'où ma suggestion de désactiver le cache dans certains cas.

Il est facile de faire un test de desactivation du cache, ce qui
fonctionnera peut-être mieux dans le cas usuel (mais ne protège plus
le serveur SQL en cas de pic de traffic sur une page).

En cas de pic de trafic, l'IO va souffrir aussi si le cache est regénéré fréquemment.

Cela dit il serait intéressant de voir un peu plus finement si par
exemple ce ne seraient pas les bots d'indexation qui génèrent la
majeur partie de la charge et si ce n'est pas juste pour eux qu'il
faudrait désactiver le cache (puisque on sait que eux ne joueront
jamais tout d'un coup des centaines de hits par seconde sur une
page)

C'est une piste qui me parait en effet intéressante. Sur certains sites, la grosse majorité des requêtes sont faites par des bots.

13

C est cool de venir ici .

Vu les différentes remarques, cela semble donc venir de tmp ...
Tu peux essayer de localiser ce qui fait les io sur les 4 sites de Nicolas ? Quels styles de fichiers ? (tmp/cache/* tmp/log/* /local/* .... ? ) et s il y a un style de fichier qui prends plus de place ?

Autre chose aussi, si jamais tu as un autre site sur la plateforme pour benchmarker ? Trouver un utilisateur qui est dans la même version de spip que Nicolas .

Oui tiens Nicolas, tu es ptet du genre à avoir bidouillé un truc aussi , non ? :wink:

14

Je suis administrateur système chez alwaysdata, je me permets de participer à la discussion pour apporter mon point de vue.
Je précise que je n'ai pas d'expérience directe avec SPIP (i.e. je n'en ai jamais installé/configuré un) ; je ne vois les choses que via le prisme du sysadmin.

C est cool de venir ici .

Je confirme, sympa de voir un hébergeur s'impliquer dans la discussion directement.

Vu les différentes remarques, cela semble donc venir de tmp ...
Tu peux essayer de localiser ce qui fait les io sur les 4 sites de Nicolas ? Quels styles de fichiers ? (tmp/cache/* tmp/log/* /local/* .... ? ) et s il y a un style de fichier qui prends plus de place ?

J'ai 3 SPIP sur cet hébergement :

http://www.marketing-planet.com/

Le premier est en SPIP 3.0.5 mais les deux autres en SPIP 3.0.0-beta2 [18897]. Je sais, c'est mal, jamais eu le temps de mettre à jour.

J'ai aussi d'autres développements PHP, mais bien plus légers à priori (à confirmer, peut-être, si Cyril a le moyen de le faire).

Autre chose aussi, si jamais tu as un autre site sur la plateforme pour benchmarker ? Trouver un utilisateur qui est dans la même version de spip que Nicolas .

Oui tiens Nicolas, tu es ptet du genre à avoir bidouillé un truc aussi , non ? :wink:

Non, c'est fini les bidouilles sur SPIP, ce que je faisais de spécifique jusqu'à présent est maintenant standard, j'essaie de rentrer dans le rang pour ne plus passer des heures à comprendre ce que j'ai fait comme bêtise… :wink:

-Nicolas

15

Ben s wrote:

Vu les différentes remarques, cela semble donc venir de tmp ... Tu
peux essayer de localiser ce qui fait les io sur les 4 sites de
Nicolas ? Quels styles de fichiers ? (tmp/cache/* tmp/log/*/local/*
.... ? ) et s il y a un style de fichier qui prends plus de place ?

Globalement, beaucoup de cache, un peu de local et sessions, et le fameux spip.log modifié en permanence.

À noter que la taille du fichier n'a (quasiment) aucune importance : ça ne coûte pas plus d'IO d'écrire un octet que d'en écrire 10000.

Autre chose aussi, si jamais tu as un autre site sur la plateforme
pour benchmarker ? Trouver un utilisateur qui est dans la même
version de spip que Nicolas .

Le seul benchmark qui vaille, en ce qui me concerne, c'est le nombre de fichiers modifiés. Trouver d'autres SPIP, ce n'est pas très dur, mais si le comportement par défaut est bien de loguer et d'avoir du cache, on risque d'avoir des résultats similaires. Y a-t-il un fichier dans une installation SPIP qui indique la version ?

Tiens d'ailleurs à propos des sessions, pourquoi ne sont-elles pas stockées dans session.save_path ? Dans notre config par défaut, le save_path va taper dans un tmpfs, ce qui économise beaucoup d'IO sans que nos clients aient à modifier quoi que ce soit.

16

Ben s wrote:

Vu les différentes remarques, cela semble donc venir de tmp ... Tu
peux essayer de localiser ce qui fait les io sur les 4 sites de
Nicolas ? Quels styles de fichiers ? (tmp/cache/* tmp/log/*/local/*
.... ? ) et s il y a un style de fichier qui prends plus de place ?

Globalement, beaucoup de cache, un peu de local et sessions, et le fameux
spip.log modifié en permanence.

Il y a peut-être moyen de réduire le ajouts au spin.log …

À noter que la taille du fichier n'a (quasiment) aucune importance : ça ne
coûte pas plus d'IO d'écrire un octet que d'en écrire 10000.

Autre chose aussi, si jamais tu as un autre site sur la plateforme

pour benchmarker ? Trouver un utilisateur qui est dans la même
version de spip que Nicolas .

Le seul benchmark qui vaille, en ce qui me concerne, c'est le nombre de
fichiers modifiés. Trouver d'autres SPIP, ce n'est pas très dur, mais si le
comportement par défaut est bien de loguer et d'avoir du cache, on risque
d'avoir des résultats similaires. Y a-t-il un fichier dans une installation
SPIP qui indique la version ?

Tiens d'ailleurs à propos des sessions, pourquoi ne sont-elles pas
stockées dans session.save_path ? Dans notre config par défaut, le
save_path va taper dans un tmpfs, ce qui économise beaucoup d'IO sans que
nos clients aient à modifier quoi que ce soit.

Ce sont des sessions spécifiques à SPIP et non les sessions natives de PHP,
si je ne m'abuse… mais je ne sais plus pourquoi.

17

Nicolas Hoizey wrote:

    Globalement, beaucoup de cache, un peu de local et sessions, et le
    fameux spip.log modifié en permanence.

Il y a peut-être moyen de réduire le ajouts au spin.log …

Si j'ai bien compris, actuellement il y a des lignes de log rajoutées à chaque requête. Impossible de faire dans la demi-mesure : l'IO n'est *pas* proportionnel au nombre d'octets, et écrire un octet par requête ou 10000, ça aura le même coût.

    Tiens d'ailleurs à propos des sessions, pourquoi ne sont-elles pas
    stockées dans session.save_path ? Dans notre config par défaut, le
    save_path va taper dans un tmpfs, ce qui économise beaucoup d'IO
    sans que nos clients aient à modifier quoi que ce soit.

Ce sont des sessions spécifiques à SPIP et non les sessions natives de
PHP, si je ne m'abuse… mais je ne sais plus pourquoi.

La plupart des autres applications stockent ça en base, dans une table simple (typiquement, clé/valeur avec index sur la clé), accessible donc ultra-rapidement.

Sur notre architecture, ce serait préférable (principalement parce qu'il est plus facile d'optimiser l'IO d'un cluster MySQL, par exemple avec du SSD), mais ce n'est pas une vérité universelle, et le stockage sur système de fichiers a aussi ses avantages.

Bref, il n'y a pas de solution magique. Peut-être avoir 2 profils de configuration par défaut, l'un qui irait plutôt taper sur le système de fichiers local (comme actuellement), et l'autre qui irait plutôt taper dans la base MySQL ?

18

2013/3/15 Cyril B. <cbay@alwaysdata.com>

Globalement, beaucoup de cache, un peu de local et sessions, et le fameux spip.log modifié en permanence.
À noter que la taille du fichier n’a (quasiment) aucune importance : ça ne coûte pas plus d’IO d’écrire un octet que d’en écrire 10000.

ok spip.log .
Voir si on ne devrait pas diminuer le niveau de log par defaut.
Nicolas rien de spécial dans mes_options ? (pas de define niveau de log verbeux ? )

Le seul benchmark qui vaille, en ce qui me concerne, c’est le nombre de fichiers modifiés. Trouver d’autres SPIP, ce n’est pas très dur, mais si le comportement par défaut est bien de loguer et d’avoir du cache, on risque d’avoir des résultats similaires. Y a-t-il un fichier dans une installation SPIP qui indique la version ?

ecrire/inc_version.php: $spip_version_branche = « 3.0.5 »;

Ben.

P.S : pas besoin de rajouter le nom de la boite en sujet :wink:

19

Globalement, beaucoup de cache, un peu de local et sessions, et le fameux
spip.log modifié en permanence.
À noter que la taille du fichier n'a (quasiment) aucune importance : ça
ne coûte pas plus d'IO d'écrire un octet que d'en écrire 10000.

ok spip.log .
Voir si on ne devrait pas diminuer le niveau de log par defaut.
Nicolas rien de spécial dans mes_options ? (pas de define niveau de log
verbeux ? )

Je n'ai que ça :
$GLOBALS['taille_des_logs'] = 5000;

Le seul benchmark qui vaille, en ce qui me concerne, c'est le nombre de

fichiers modifiés. Trouver d'autres SPIP, ce n'est pas très dur, mais si le
comportement par défaut est bien de loguer et d'avoir du cache, on risque
d'avoir des résultats similaires. Y a-t-il un fichier dans une installation
SPIP qui indique la version ?

ecrire/inc_version.php: $spip_version_branche = "3.0.5";

P.S : pas besoin de rajouter le nom de la boite en sujet :wink:

Pas faux. C'est moi qui l'avait mis pour indiquer la provenance.

20

Nicolas Hoizey wrote:

    Globalement, beaucoup de cache, un peu de local et sessions, et le
    fameux spip.log modifié en permanence.

Il y a peut-être moyen de réduire le ajouts au spin.log …

Si j'ai bien compris, actuellement il y a des lignes de log rajoutées à
chaque requête. Impossible de faire dans la demi-mesure : l'IO n'est *pas*
proportionnel au nombre d'octets, et écrire un octet par requête ou 10000,
ça aura le même coût.

Si on ne met que les erreurs dans le log, il «devrait» rester vide…