[spip-dev] Impact de SPIP sur les I/O disque

Dev
1

C’est impressionnant à quel point on gagne en vitesse lorsqu’on passe tmp/ en tmpfs :
Je l’ai fais pour http://forum.spip.net/, le gain de vitesse est bluffant.
(aucun test réel, juste perceptif)

On pourrait atteindre des perfs équivalentes en supprimant tout log (sont-ils utiles en prod ?) et en mettant les caches SPIP en mémoire ou en base de données ?

Mes deux sous,

.Gilles

2

* Gilles Vincent tapuscrivait, le 19/03/2013 17:51:

C'est impressionnant à quel point on gagne en vitesse lorsqu'on passe tmp/
en tmpfs :

Concrètement, tu fais ça comment ?

De mon côté, mon infogérant utilise du RAMdisk pour le dossier tmp/ C'est pas mal aussi côté perf.

3

C’est impressionnant à quel point on gagne en vitesse lorsqu’on passe tmp/ en tmpfs :
Je l’ai fais pour http://forum.spip.net/, le gain de vitesse est bluffant.
(aucun test réel, juste perceptif)

On pourrait atteindre des perfs équivalentes en supprimant tout log (sont-ils utiles en prod ?)

SPIP 3 ne log plus que les erreurs par défaut (ce qui est tout de même utile)

et en mettant les caches SPIP en mémoire ou en base de données ?

en mémoire avec memoization → xcache ou APC
mais il m’arrive de préférer utiliser memoization/filecache et de placer _DIR_CACHE sur /dev/shm/ (c’est la config actuelle de contrib)

Cédric

4

2013/3/19 Cédric Morin <cedric.morin@yterium.com>

C’est impressionnant à quel point on gagne en vitesse lorsqu’on passe tmp/ en tmpfs :
Je l’ai fais pour http://forum.spip.net/, le gain de vitesse est bluffant.
(aucun test réel, juste perceptif)

On pourrait atteindre des perfs équivalentes en supprimant tout log (sont-ils utiles en prod ?)

SPIP 3 ne log plus que les erreurs par défaut (ce qui est tout de même utile)

Les plugins sont souvent beaucoup plus verbeux
Mais effectivement j’ai choisi de garder les logs (que j’ai mis en tmpfs, vu que leur durée de vie est très très courte et qu’ils sont modifiés très souvent)

et en mettant les caches SPIP en mémoire ou en base de données ?

en mémoire avec memoization → xcache ou APC
mais il m’arrive de préférer utiliser memoization/filecache et de placer _DIR_CACHE sur /dev/shm/ (c’est la config actuelle de contrib)

J’ai pris la même configuration.

5

Par curiosité, c'est tout fait dans mémoization, ou vous avez une recette en plus dans mes_options ou je ne sais où ?

MM.

6

2013/3/19 Cédric Morin <cedric.morin@yterium.com>

C’est impressionnant à quel point on gagne en vitesse lorsqu’on passe tmp/ en tmpfs :
Je l’ai fais pour http://forum.spip.net/, le gain de vitesse est bluffant.
(aucun test réel, juste perceptif)

On pourrait atteindre des perfs équivalentes en supprimant tout log (sont-ils utiles en prod ?)

SPIP 3 ne log plus que les erreurs par défaut (ce qui est tout de même utile)

C’est étonnant, en regardant les commentaires de spip_log(), j’ai l’impression du contraire

  • Enregistrement des evenements
  • spip_log($message)
  • spip_log($message,‹ recherche ›)
  • spip_log($message,_LOG_DEBUG)
  • spip_log($message,‹ recherche. ›._LOG_DEBUG)
  • cette derniere notation est controversee mais le 3eme
  • parametre est plante pour cause de compat ascendante.
  • le niveau par defaut est _LOG_INFO
7

NonLe niveau par défaut est bien _LOG_INFO
Et par défaut seuls les logs de niveau _LOG_INFO_IMPORTANTE ou plus sont écrits dans le journal

Cedric

8

2013/3/19 Cédric Morin <cedric.morin@yterium.com>

Ca devrait plutôt être _LOG_ERREUR, voire _LOG_CRITIQUE, non ?

NonLe niveau par défaut est bien _LOG_INFO
Et par défaut seuls les logs de niveau _LOG_INFO_IMPORTANTE ou plus sont écrits dans le journal

Au temps pour moi,
j’ai lu trop vite la ligne
http://core.spip.org/projects/spip/repository/entry/branches/spip-3.0/ecrire/inc/utils.php#L196

.Gilles