Project

General

Profile

Anomalie #4261

Vider l'opcache au recalcul et à l'upgrade

Added by jluc - 4 months ago. Updated about 2 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
01/02/2019
Due date:
% Done:

0%

Resolution:
Navigateur:

Description

Quand un code est dans l'opcache, il faut beaucoup de cheveux pour le raffraîchir vraiment... ou bien appeler opcache_reset.

Quand je modifie un squelette et que raffraîchir varnish ne fait rien, je constate qu'appeler opcache_reset avant un recalcul permet la mise à jour immédiate.

Par ailleurs, aprés un upgrade, j'ai constaté que mon site utilisait des anciennes fonctions qui n'étaient plus définies. Malgré vidage de cache/skels, les cache/skels php étaient toujours regénérés avec un appel à l'ancienne fonction qui n'était plus ni définie ni utilisée nulle part ! Je pense qu'appeler qu'opcache_reset aurait bien aidé à se débarrasser de cette mauvaise habitude.

Il y a peut être d'autres contextes où ce serait nécessaire.

Je propose d'ajouter le code suivant quand ?var_mode=recalcul et à chaque upgrade d'un plugin ou de spip :

if (function_exists('opcache_reset')) {
opcache_reset();
}

History

#1 Updated by jluc - 4 months ago

Dans le noyau de SPIP une fonction spip_clear_opcode_cache est définie et utilisée dans ecrire_fichier et ecrire_fichier_php, mais
  1. c'est des fonctions qui ne s'occupent que d'un seul fichier, et qui ne sont (probablement) pas appelées quand on modifie tout un répertoire d'une mise à jour
  2. c'est pas défini et donc pas fait avec spip_loader alors que d'immenses portions de code sont changées...
  3. si c'est le dev qui a modifié le source d'un squelette, spip n'en est pas informé et ça ne passe pas a priori par un ecrire_fichier. Lors du recalcul il faut intégrer ce besoin.

#2 Updated by jluc - 4 months ago

Voilà ce que j'ai ajouté dans mon fichier d'option :

if (isset($_REQUEST['var_mode']) and ($_REQUEST['var_mode'] == 'recalcul')) {

    if (function_exists('spip_clear_varnish_cache'))
        spip_clear_varnish_cache();

    include_spip ('inc/invalideur');
    suivre_invalideur('recalcul');

    if (function_exists('opcache_reset'))
        opcache_reset();

    if (function_exists('apc_clear_cache')) {
        apc_clear_cache();
        apc_clear_cache('user');
    }
    spip_log("recalcul a vidé varnish, SPIP, opcache et apc_cache");
}

C'est un peu radical mais il n'y a pas pire que du code zombie qui traîne et colle dans les recoins d'un cache en produisant des résultats aberrant sans qu'on puisse s'en débarrasser.

#3 Updated by jluc - 4 months ago

Peut être faudrait il faire les bases dans le noyau et ajouter un pipeline pour le reste ?

#4 Updated by jluc - 3 months ago

Et donc, si ça semble préférable, passer à ce pipeline commun un argument indiquant le contexte spécifique d'invalidation : recalcul, install ou upgrade plugin, upgrade spip, etc

#5 Updated by b b 2 months ago

  • Target version set to 3.3

#6 Updated by jluc - about 2 months ago

Certains hébergeurs restreignent l'accès à ces fonctions et il semble que leur appel produise un warning " Zend OPcache API is restricted by "restrict_api" configuration directive". Donc ajouter un @ aux appels :

 @opcache_reset(); @ apc_clear_cache(); @apc_clear_cache('user');

Also available in: Atom PDF