[spip-dev] r20936 - branches/spip-2.1/ecrire/inc

Dev
1

Désolé si j'ai envoyé plusieurs fois, mais ça ne semble pas vouloir partir sur les listes. Je retente !

Bravo pour avoir trouvé le bug !
Mais… on ne peut pas invalider opcache à chaque écriture dans un fichier, ça va tuer la perf (vu qu’on log à chaque hit, on invalide à chaque hit).

Peux tu préciser ?

Il me semble que ce cache est un cache sur la lecture d'un fichier (compilé en php) qui évite de rouvrir le fichier 2 fois de suite SI le fichier n'a pas changé. Le fait qu'on log, et qu'on invalide les fichiers de log à l'écriture, en quoi cela gênerait, vu que ces fichiers sont simplement écris plusieurs fois par hit, mais non lus ?

J'ai cru comprendre que l'actualisation du cache opcache se base normalement sur le timestamp du fichier, mais cette donnée qui était recalculée toutes les 2 secondes, n'est maintenant plus calculée qu'une fois par hit en php 5.5 (je me trompe peut être dans ma compréhension, parce que je vois pas pourquoi on n'aurait pas eu ces problèmes même avec 2 secondes de délai…)

Là on dit que si un fichier est écrit, d'invalider le cache opcache de *ce* fichier pour que la prochaine lecture soit réellement à jour de ses données.

C'est ennuyant effectivement pour les fichiers de tmp/cache/*/* qui ne changent pas, à priori plus d'une fois par hit, mais les fichiers de session et de cache de pipelines/options/fonctions ou spip_meta le sont.

On n'invalide pas tout l'opcache tout de même.

Peut être y a t'il moyen de mieux cibler les fichiers concernés cependant. Mais j'ai peur que ça perturbe d'autres utilisations qu'on a pas encore vues.

Sans cette correction en tout cas, par exemple, en plus des plugins qui ne s'installaient pas, actuellement avec php 5.5.3, session_set('x', 10) suivi de session_get('x') ne retourne pas le bon résultat. Il suffit d'exécuter 2 fois session_set/session_get avec des valeurs différentes pour s'en rendre compte.

session_set('x', 10)
session_get('x')

session_set('x', 20)
session_get('x')

Je veux bien une meilleure solution cependant hein :slight_smile:

En attendant, ça corrige ces problèmes…

MM.

2

Désolé si j'ai envoyé plusieurs fois, mais ça ne semble pas vouloir partir sur les listes. Je retente !

Bravo pour avoir trouvé le bug !
Mais… on ne peut pas invalider opcache à chaque écriture dans un fichier, ça va tuer la perf (vu qu’on log à chaque hit, on invalide à chaque hit).

Peux tu préciser ?

Il me semble que ce cache est un cache sur la lecture d'un fichier (compilé en php) qui évite de rouvrir le fichier 2 fois de suite SI le fichier n'a pas changé. Le fait qu'on log, et qu'on invalide les fichiers de log à l'écriture, en quoi cela gênerait, vu que ces fichiers sont simplement écris plusieurs fois par hit, mais non lus ?

oui en effet j’ai lu trop vite, cela porte bien sur le fichier qu’on vient d’écrire, my fault.

J'ai cru comprendre que l'actualisation du cache opcache se base normalement sur le timestamp du fichier, mais cette donnée qui était recalculée toutes les 2 secondes, n'est maintenant plus calculée qu'une fois par hit en php 5.5 (je me trompe peut être dans ma compréhension, parce que je vois pas pourquoi on n'aurait pas eu ces problèmes même avec 2 secondes de délai…)

Là on dit que si un fichier est écrit, d'invalider le cache opcache de *ce* fichier pour que la prochaine lecture soit réellement à jour de ses données.

C'est ennuyant effectivement pour les fichiers de tmp/cache/*/* qui ne changent pas, à priori plus d'une fois par hit, mais les fichiers de session et de cache de pipelines/options/fonctions ou spip_meta le sont.

Ah oui il y a aussi les fichiers de session, tu as raison.
Donc je retire tout ce que j’ai dit !

On n'invalide pas tout l'opcache tout de même.

Peut être y a t'il moyen de mieux cibler les fichiers concernés cependant. Mais j'ai peur que ça perturbe d'autres utilisations qu'on a pas encore vues.

Peut-être qu’il serait judicieux d’éviter l’appel pour les fichier qui ne sont pas du type .php, mais c’est sans doute epsilon par rapport à ce que j’avais cru comprendre, à savoir l’invalidation du cache opcode.

Ça a l’air un joli merdier leur APC natif, quand tu vois que XCache marche très bien tout seul sans rien avoir à faire dans le PHP…

Sans cette correction en tout cas, par exemple, en plus des plugins qui ne s'installaient pas, actuellement avec php 5.5.3, session_set('x', 10) suivi de session_get('x') ne retourne pas le bon résultat. Il suffit d'exécuter 2 fois session_set/session_get avec des valeurs différentes pour s'en rendre compte.

session_set('x', 10)
session_get('x')

session_set('x', 20)
session_get('x')

Je veux bien une meilleure solution cependant hein :slight_smile:

Nan, c’est parfait, je me fouette céans de ma réaction alarmiste inutile !

Cédric