[spip-dev] SPIP, NFS et performance

Hello,
après quelques recherches biblio sur NFS et les problèmes de perf, j’ai trouvé cet article intéressant, qui semble pouvoir s’appliquer également à SPIP.

http://tag1consulting.com/blog/nfs-drupal-and-realpath-cache

Le fait est que quasi toutes les inclusions passent par include_once (via include_spip ou find_in_path), et qu’il semble que cela déclenche un lstat sur NFS à chaque fois (y compris en cas d’include multiples sur le même fichier), ce qui semble très mauvais en terme de perf, donc, si par malheur le cache sur le real_path n’est pas assez gros (peut-il l’être dans le cas d’un mutu ? si un hébergeur compétent est dans la salle et nous écoute, réponse bienvenue …).

Un fix semblerait être de spécifier le chemin absolu dans la directive include_once.
Il me semble que dans notre cas, il serait assez trivial d’ajouter 1 ligne dans spip_initialisation_core() :
define(’_CWD’,getcwd());

et de modifier la fonction find_in_path par

if (is_readable($a .= $file)) {
if ($include) include_once $a;
return $files[$dirname][$file] = $files[’’][$dirname . $file] = $a;
}

en
if (is_readable($a .= $file)) {
$a = _CWD . $a;
if ($include) include_once $a;
return $files[$dirname][$file] = $files[’’][$dirname . $file] = $a;
}

ce qui aura de plus l’avantage d’eviter que php ne recherche dans le include_path au moment du include_once.
Les quelques appels directs a include_once pourraient aussi être prefixés de la meme façon, mais c’est anectodique il me semble.

L’autre piste que je vois serais de ne plus effectuer coté script php la recherche dans le path, mais de se reposer sur php lui même et include_path (on peut présumer que cette recherche est plus rapide)
Cela ne permettra cependant de traiter que les cas d’inclusion (je ne suis pas sur que l’on puisse récuperer le chemin du fichier inclus pour le retourner, le cas échéant, donc il est possible que cela ne couvre pas 100% des inclusions).

Dans tous les cas, un site hébérgé en mutu et qui présente des problèmes de lenteur, voire d’erreurs 500 intempestives, serait nécessaire pour valider le patch.
Si un candidat est volontaire, c’est assez simple à essayer !

Cédric

Cédric Morin a écrit :

Hello,
après quelques recherches biblio sur NFS et les problèmes de perf, j'ai trouvé cet article intéressant, qui semble pouvoir s'appliquer également à SPIP.

NFS, Drupal And The Realpath Cache | Tag1 Consulting

Le fait est que quasi toutes les inclusions passent par include_once (via include_spip ou find_in_path), et qu'il semble que cela déclenche un lstat sur NFS à chaque fois (y compris en cas d'include multiples sur le même fichier), ce qui semble très mauvais en terme de perf, donc, si par malheur le cache sur le real_path n'est pas assez gros (peut-il l'être dans le cas d'un mutu ? si un hébergeur compétent est dans la salle et nous écoute, réponse bienvenue ...).

Un fix semblerait être de spécifier le chemin absolu dans la directive include_once.
Il me semble que dans notre cas, il serait assez trivial d'ajouter 1 ligne dans spip_initialisation_core() :
define('_CWD',getcwd());

et de modifier la fonction find_in_path par

            if (is_readable($a .= $file)) {
                if ($include) include_once $a;
                return $files[$dirname][$file] = $files[''][$dirname . $file] = $a;
            }

en
            if (is_readable($a .= $file)) {
                $a = _CWD . $a;
                if ($include) include_once $a;
                return $files[$dirname][$file] = $files[''][$dirname . $file] = $a;
            }

ce qui aura de plus l'avantage d'eviter que php ne recherche dans le include_path au moment du include_once.
Les quelques appels directs a include_once pourraient aussi être prefixés de la meme façon, mais c'est anectodique il me semble.

L'autre piste que je vois serais de ne plus effectuer coté script php la recherche dans le path, mais de se reposer sur php lui même et include_path (on peut présumer que cette recherche est plus rapide)
Cela ne permettra cependant de traiter que les cas d'inclusion (je ne suis pas sur que l'on puisse récuperer le chemin du fichier inclus pour le retourner, le cas échéant, donc il est possible que cela ne couvre pas 100% des inclusions).

Dans tous les cas, un site hébérgé en mutu et qui présente des problèmes de lenteur, voire d'erreurs 500 intempestives, serait nécessaire pour valider le patch.
Si un candidat est volontaire, c'est assez simple à essayer !

Cédric

pas très bien compris le détail, mais je pense que je peux tester sur ouvaton (ceci dit, je n'ai pas très souvent d'erreur 500)

Oui, c'était un patch de principe, le vrai qui marche est
http://trac.rezo.net/trac/spip/changeset/14743

Cédric Morin a écrit :

Mon premier patch n’ayant pas été révolutionnaire, je suis repassé sur le métier pour gratter vraiment partout où c’était possible, ce qui a valu une série de modifs :

http://trac.rezo.net/trac/spip/changeset/14743
http://trac.rezo.net/trac/spip/changeset/14746
http://trac.rezo.net/trac/spip/changeset/14748
http://trac.rezo.net/trac/spip/changeset/14749
http://trac.rezo.net/trac/spip/changeset/14750
http://trac.rezo.net/trac/spip/changeset/14754
http://trac.rezo.net/trac/spip/changeset/14755

http://trac.rezo.net/trac/spip/changeset/14756
http://trac.rezo.net/trac/spip/changeset/14757
http://trac.rezo.net/trac/spip/changeset/14758
http://trac.rezo.net/trac/spip/changeset/14759

Les fichiers modifiés dans ecrire/ sont :

inc_version.php
public/composer.php
public/compiler.php
inc/flock.php
public/composer.php
action/purger.php
inc/plugin.php
public.php
action/purger.php
inc/utils.php
public/cacher.php

Ca tourne en test sur contrib, et il semble que j’ai réglé tous les petits problèmes de jeunesse.
Je suis preneur de tout retour !

Cédric

cedric.morin@yterium.com a écrit :

Cédric Morin a écrit :

Cédric Morin a écrit :
   

Hello,
après quelques recherches biblio sur NFS et les problèmes de perf, j'ai
trouvé cet article intéressant, qui semble pouvoir s'appliquer également à
SPIP.

NFS, Drupal And The Realpath Cache | Tag1 Consulting

Le fait est que quasi toutes les inclusions passent par include_once (via
include_spip ou find_in_path), et qu'il semble que cela déclenche un lstat
sur NFS à chaque fois (y compris en cas d'include multiples sur le même
fichier), ce qui semble très mauvais en terme de perf, donc, si par malheur
le cache sur le real_path n'est pas assez gros (peut-il l'être dans le cas
d'un mutu ? si un hébergeur compétent est dans la salle et nous écoute,
réponse bienvenue ...).

Un fix semblerait être de spécifier le chemin absolu dans la directive
include_once.
...
ce qui aura de plus l'avantage d'eviter que php ne recherche dans le
include_path au moment du include_once.
Les quelques appels directs a include_once pourraient aussi être prefixés
de la meme façon, mais c'est anectodique il me semble.

L'autre piste que je vois serais de ne plus effectuer coté script php la
recherche dans le path, mais de se reposer sur php lui même et include_path
(on peut présumer que cette recherche est plus rapide)
Cela ne permettra cependant de traiter que les cas d'inclusion (je ne suis
pas sur que l'on puisse récuperer le chemin du fichier inclus pour le
retourner, le cas échéant, donc il est possible que cela ne couvre pas 100%
des inclusions).

Dans tous les cas, un site hébérgé en mutu et qui présente des problèmes
de lenteur, voire d'erreurs 500 intempestives, serait nécessaire pour
valider le patch.
Si un candidat est volontaire, c'est assez simple à essayer !

Cédric
------------------------------------------------------------------------

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip
     

Syndrome de la page blanche en appliquant le patch proposé.

Oui, c'était un patch de principe, le vrai qui marche est
http://trac.rezo.net/trac/spip/changeset/14743
+
http://trac.rezo.net/trac/spip/changeset/14746

Mais je suis en train de travailler sur une proposition plus complète,
qui essaie d'optimiser tous les accès disques :
- en deleguant l'inclusion dans le path à php au lieu de faire une
recherche itérative, comme je le proposais plus haut
- en mutualisant au maximum les accès à un même fichier comme par
exemple en évitant de faire un file_exists() suivi d'un
lire_fichier(), qui vont provoquer 2 accès au filer, alors que le
lire_fichier renverra directement l'information que le fichier
n'existe pas.

La difficulté est que je ne vois pas forcément d'impact de perfo avec
un disque local, et qu'il faudra tester sur un hébergement avec filer
quand ce sera près.
Je pense que je vais faire une branche test sur la 2.0 pour pouvoir tester.

Cédric

Assez routinier, mes squelettes sont essentiellement basés sur des #INCLURE et autres #MODELES.
Je suis preneur de tout ce qui peut optimiser l'accès aux disques
LA démarche proposé me parait une voie intéressante.

Mon premier patch n'ayant pas été révolutionnaire, je suis repassé sur le métier pour gratter vraiment partout où c'était possible, ce qui a valu une série de modifs :

http://trac.rezo.net/trac/spip/changeset/14743
http://trac.rezo.net/trac/spip/changeset/14746
http://trac.rezo.net/trac/spip/changeset/14748
http://trac.rezo.net/trac/spip/changeset/14749
http://trac.rezo.net/trac/spip/changeset/14750
http://trac.rezo.net/trac/spip/changeset/14754
http://trac.rezo.net/trac/spip/changeset/14755
http://trac.rezo.net/trac/spip/changeset/14756
http://trac.rezo.net/trac/spip/changeset/14757
http://trac.rezo.net/trac/spip/changeset/14758
http://trac.rezo.net/trac/spip/changeset/14759 <http://trac.rezo.net/trac/spip/changeset/1475&gt;

Les fichiers modifiés dans ecrire/ sont :

inc_version.php
public/composer.php
public/compiler.php
inc/flock.php
public/composer.php
action/purger.php
inc/plugin.php
public.php
action/purger.php
inc/utils.php
public/cacher.php

Ca tourne en test sur contrib, et il semble que j'ai réglé tous les petits problèmes de jeunesse.
Je suis preneur de tout retour !

Cédric

Je testerai ce nouvel ensemble dès ce soir. Je suis hébergé en mutualisé chez Nuxit.
Retour demain dans la journée

Claude

Cédric Morin a écrit :

Cédric Morin a écrit :

Hello,
après quelques recherches biblio sur NFS et les problèmes de perf, j’ai
trouvé cet article intéressant, qui semble pouvoir s’appliquer également à
SPIP.

http://tag1consulting.com/blog/nfs-drupal-and-realpath-cache

Le fait est que quasi toutes les inclusions passent par include_once (via
include_spip ou find_in_path), et qu’il semble que cela déclenche un lstat
sur NFS à chaque fois (y compris en cas d’include multiples sur le même
fichier), ce qui semble très mauvais en terme de perf, donc, si par malheur
le cache sur le real_path n’est pas assez gros (peut-il l’être dans le cas
d’un mutu ? si un hébergeur compétent est dans la salle et nous écoute,
réponse bienvenue …).

[…]

Mon premier patch n’ayant pas été révolutionnaire, je suis repassé sur le métier pour gratter vraiment partout où c’était possible, ce qui a valu une série de modifs :

http://trac.rezo.net/trac/spip/changeset/14743

http://trac.rezo.net/trac/spip/changeset/14746

http://trac.rezo.net/trac/spip/changeset/14748

http://trac.rezo.net/trac/spip/changeset/14749

http://trac.rezo.net/trac/spip/changeset/14750

http://trac.rezo.net/trac/spip/changeset/14754

http://trac.rezo.net/trac/spip/changeset/14755

http://trac.rezo.net/trac/spip/changeset/14756

http://trac.rezo.net/trac/spip/changeset/14757

http://trac.rezo.net/trac/spip/changeset/14758

http://trac.rezo.net/trac/spip/changeset/14759

Les fichiers modifiés dans ecrire/ sont :

inc_version.php

public/composer.php

public/compiler.php

inc/flock.php

public/composer.php

action/purger.php

inc/plugin.php

public.php

action/purger.php

inc/utils.php

public/cacher.php

Ca tourne en test sur contrib, et il semble que j’ai réglé tous les petits problèmes de jeunesse.

Je suis preneur de tout retour !

Salut,

Je pense avoir compris la suggestion en terme PHP.
Ceci dit, peut-on avoir une idée des caractéristiques systèmes permettant d’arriver à la conclusion trop de lstat ?

Le montage nfs se faisait en udp ? tcp ? avec gestion de cache read ? write ? avec ou sans gestion atime ? Les disques sont de quelle structure ? vitesse ? quel cache matériel ?

Quand on dit filer on parle d’un serveur PC qui fait nfsd ou un d’un Netapp FASxxxx ?

Bref, avant de relire le code, et je félicité Cédric de taper là où il sait, j’aimerai travailler de concert sur la partie « en dessous », là où je connais un peu mieux face-smile.png

A+

Ouch.
Malheureusement, c’est un morceau que je ne connais pas, et je serais bien incapable de répondre.
Je suis parti des plaintes d’un hébergeur ([http://blog.ouvaton.org/index.php?post/2009/11/13/SPIP-2,-SarkaSPIP-et-node1-5 pour ne pas le citer](http://blog.ouvaton.org/index.php?post/2009/11/13/SPIP-2,-SarkaSPIP-et-node1-5 pour ne pas le citer))
J’ai lu un peu de doc et notamment ce post qui concernant drupal, et j’ai constaté que SPIP avait le même défaut.
J’ai donc corrigé ce défaut à la source, et d’après ce que j’ai vu, cela améliore même en cas de serveur avec disque local.
Donc j’ose espérer qu’en NFS ce sera aussi le cas, mais je n’ai pas de moyen de test.

Merci à toi et à lautre.net de t’intéresser à nos tentatives d’amélioration !

Cédric

Ouch.
Malheureusement, c’est un morceau que je ne connais pas, et je serais bien incapable de répondre.
Je suis parti des plaintes d’un hébergeur (http://blog.ouvaton.org/index.php?post/2009/11/13/SPIP-2,-SarkaSPIP-et-node1-5 pour ne pas le citer)
J’ai lu un peu de doc et notamment ce post qui concernant drupal, et j’ai constaté que SPIP avait le même défaut.
J’ai donc corrigé ce défaut à la source, et d’après ce que j’ai vu, cela améliore même en cas de serveur avec disque local.
Donc j’ose espérer qu’en NFS ce sera aussi le cas, mais je n’ai pas de moyen de test.

Merci à toi et à lautre.net de t’intéresser à nos tentatives d’amélioration !

Cédric

Je viens d’upgrader 2 spip2 sur mon semi-mutu-sur-mesure. Je demanderai à mon hébergeur s’il a vu une différence…

Ouch.

Malheureusement, c’est un morceau que je ne connais pas, et je serais bien incapable de répondre.

Je suis parti des plaintes d’un hébergeur (http://blog.ouvaton.org/index.php?post/2009/11/13/SPIP-2,-SarkaSPIP-et-node1-5 pour ne pas le citer)

J’ai lu un peu de doc et notamment ce post qui concernant drupal, et j’ai constaté que SPIP avait le même défaut.

J’ai donc corrigé ce défaut à la source, et d’après ce que j’ai vu, cela améliore même en cas de serveur avec disque local.

Donc j’ose espérer qu’en NFS ce sera aussi le cas, mais je n’ai pas de moyen de test.

Merci à toi et à lautre.net de t’intéresser à nos tentatives d’amélioration !

A titre expérimental, Benjamin a changé un paramètre sur L’Autre Net, sur un seul client NFS pour l’instant, le realcache_path (paramètre PHP) est passé de 16k à 1M.
Nous vous tenons au courant d’éventuelles améliorations.

A+

2009/11/25 L’oiseau2nuit <l.oiseau2nuit@gmail.com>

Je viens d’upgrader 2 spip2 sur mon semi-mutu-sur-mesure. Je demanderai à mon hébergeur s’il a vu une différence…

Bon… j’ai pas encore les retours de mon hébergeur par contre en terme de perfs, à l’affichage des pages, moi je la vois la différence et c’est plus que positif !

L'oiseau2nuit a écrit :

2009/11/25 L'oiseau2nuit <l.oiseau2nuit@gmail.com <mailto:l.oiseau2nuit@gmail.com>>

    Je viens d'upgrader 2 spip2 sur mon semi-mutu-sur-mesure. Je
    demanderai à mon hébergeur s'il a vu une différence...

Bon... j'ai pas encore les retours de mon hébergeur par contre en terme de perfs, à l'affichage des pages, moi je la vois la différence et c'est plus que positif !

passage en svn + php5?