temps de génération de page - Page 1

Yop !

j'ai un petit pb de temps de génération de page.

Lors de la première visualisation, la page met 0,6 secondes à se générer
Lors des visualisations suivantes, la page met 0.02 secondes à se générer

pourquoi un tel ecart, alors qu'apparement mon cache MySQL est désactivé ?


voici les variables MySQL relatives au cache :

Array
(
    [binlog_cache_size] => 32768
    [have_query_cache] => YES
    [key_cache_age_threshold] => 300
    [key_cache_block_size] => 1024
    [key_cache_division_limit] => 100
    [max_binlog_cache_size] => 4294967295
    [query_cache_limit] => 1048576
    [query_cache_min_res_unit] => 4096
    [query_cache_size] => 0
    [query_cache_type] => ON
    [query_cache_wlock_invalidate] => OFF
    [table_cache] => 64
    [thread_cache_size] => 0
)

c'est pas PHP qui a un cache?

ben normalement non... le site c'est moi qui l'ai conçu => pas de cache dedans Et il me semble pas avoir mis en place l'extension de cache PHP. Ça se vérifie comment ça ?

car je trouve que vu la "simplicitité" de la page, 0,6s c'est énorme, et j'aimerais bien l'optimiser un peu, mais à cause de cette différence de temps de génération, une fois la première visualisation effectuée, je ne peux plus vérifier si je fais baisser ou non le temps de génération...

(pour info, la page en question, c'est la premiere page de http://prgm.spipu.net/, sans choisir de catégorie)

Petit test : tu affiches la page, tu modifies ta bdd, tu réaffiches ta page...
Il se passe quoi ? (c'est peut-être juste qu'il y a une mémoire des connexions et qu'il n'a pas à les renégocier totalement, je ne sais pas).

quand tu dis "tu modifies ta bdd", tu parles de rajouter un enregistrement ? ou de modifier la structure ?

Ajouter un enregistrement.

ben je vais tester.

déjà, ca n'a rien à voir avec l'ouverture de session. Une fois que la première visualisation a eu lieu, si je ferme le navigateur (FF) et que je le réouvre en vidant tout, et que je réaffiche la page, le temps de génération est de l'ordre de 0,02 secondes.

j'ai l'impression que ca a un lien avec la première ouverture de fichiers PHP. une fois qu'ils ont déjà été ouverts, c'est possible qu'ils soient mis en cache par PHP ? (je parle des fichiers PHP, pas du résultat html)

Spipu (./7) :
(je parle des fichiers PHP, pas du résultat html)

Oui, j'ai bien compris, sinon t'aurais pas un *temps de génération*.
Là, je ne sais pas, ça doit dépendre des versions, des paramètres généraux, des optimisations... Mais je sais que PHP peut parser le fichier à la première lecture pour le prétraiter (un peu comme une tokenisation) et ne plus le toucher par la suite s'il n'est pas modifié. Ca pourrait correspondre.

bon, ben j'ai modifier un enregistrement de la base qui était pris en compte dans l'affichage : la page a bien été modifiée en fonction de cela. J'ai eu un temps de génération de l'ordre de 0.025s dans les 2 cas.

Nil (./8) :
Là, je ne sais pas, ça doit dépendre des versions, des paramètres généraux, des optimisations... Mais je sais que PHP peut parser le fichier à la première lecture pour le prétraiter (un peu comme une tokenisation) et ne plus le toucher par la suite s'il n'est pas modifié. Ca pourrait correspondre.

en effet sauf que pour tester, il faudrait que je fasse quoi ? tiens, je vais redémarrer mon apache et voir le temps de génération

[EDIT] après redémarrage d'apache, rien n'a changé, tjrs 0.025s de génération

Alors là, aucune idée, il faudrait voir des outils de bench PHP au niveau système, j'imagine, mais je ne connais pas assez.

rahhh ca m'énerve ! car je trouve que 0.6s c'est hyper long !!! et j'aimerais bien l'optimiser !

à moins que ca vienne d'un autre pb, vu que je fais tous les tests sur mon serveur de dev (= mon pc perso sous windows, avec la mise en veille des HDD automatique au bout de 2 hrs)... c'est qu'il faut le temps que les DD se remettent en marche. (sauf que pour le coup, dans ce cas, 0,6s ca me parait pas énorme...)

[EDIT] je viens de vérifier, j'avais désactivé l'arrêt automatique des disques ils tournaient sans arrêt depuis je sais pas quand... je viens de le remettre @ 2 hrs

Spipu (./8) :
une fois qu'ils ont déjà été ouverts, c'est possible qu'ils soient mis en cache par PHP ?

mieux, par le cache disque de linux aussi

(mais bon, apparemment c'est pas ça)

squalyl (./13) :
mieux, par le cache disque de linux aussi

ca, ca explique la différence de rapidité sur mon serveur de prod.

il me semble que les scripts php sont plus ou moins tokenisés à la première utilisation (m'enfin je dis peut être n'importe quoi, c'est à confirmer )

Pen^2 (./15) :
il me semble que les scripts php sont plus ou moins tokenisés à la première utilisation

le lancement d'un script PHP passe normalement par deux (trois) étapes :
- chargement du fichier
- compilation en "opcodes"
- exécution de ces opcodes
la compilation se faisant, dans le cas général, à chaque chargement d'un script.

Pour éviter de se re-tapper la compilation à chaque chargement de page, il existe des extensions permettant de cacher (au sens "mettre en cache") les opcodes - on a tendance à les appeler "cache d'opcode"
En libre et/ou gratuit, il y a au moins :
- APC : http://pecl.php.net/package/APC ; sans doute le cache d'opcode le plus connu, auquel participe Rasmus Lerdorf (fondateur de PHP, dans le temps)
- eAccelerator : http://eaccelerator.net/
- XCache : http://xcache.lighttpd.net/
Jamais testé les deux derniers ; j'utilise fréquemment le premier ; de manière générale, on dit (à la louche) que ça diminue de 50% la charge CPU d'un serveur, quand on l'installe ; j'ai entendu le même genre de chose pour les deux autres.

Par contre, sur un hébergement mutualisé, ça m'étonnerait fortement que ça soit disponible ^^
(ça bouffe pas mal en RAM - sans compter que, du moins pour APC, on peut l'utiliser comme cache de données, plus rapide que de cacher en fichier - selon le type/volumétrie des données)

Je dois pouvoir retrouver dans mes bookmarks une paire de liens intéressants à ce sujet (vers des articles qui datent un peu, mais le principe reste vrai)
- http://2bits.com/articles/php-op-code-caches-accelerators-a-must-for-a-large-site.html avec quelques graphe qui donnent une idée avant/après activation d'un cache d'opcoce
- http://2bits.com/articles/benchmarking-apc-vs-eaccelerator-using-drupal.html pour une brève comparaison en perfs eAccelerator vs APC
- http://www.ipersec.com/index.php/2006/05/30/benchmarking-php-accelerators/