web-dev-qa-db-fra.com

Laravel et voir la mise en cache en développement - impossible de voir les modifications tout de suite

Quelques amis et moi avons décidé de commencer à travailler sur un projet et nous sommes tombés sur Laravel et avons pensé que ce pourrait être un bon outil. Nous avons commencé à l'utiliser localement pour développer certaines de nos pages et avons remarqué quelque chose d'étrange.

Lorsque nous mettons à jour une vue avec des informations différentes, il faudrait environ 5 à 10 minutes avant que les vues changent. C'est comme si Laravel mettait en cache la vue et mettait un TTL dessus. 

Je sais que ce n'est pas quelque chose que je fais sur mon serveur Web local car j'ai utilisé d'autres frameworks et je n'ai jamais rencontré ce problème.

Lors de la recherche sur Internet, je ne trouve pas de bonne réponse sur la manière de désactiver ceci. Je souhaite utiliser Laravel, mais je le trouve inutile si la mise à jour de mes vues prend un certain temps à chaque fois que je souhaite apporter une modification. En fait, cela semble contre-productif.

Est-il possible de désactiver cela? Pourquoi mon point de vue prend-il une éternité à mettre à jour immédiatement?

phpcachinglaravellaravel-4
19
Sethen

Le canal #laravel IRC est un envoi de Dieu. Cela n'avait rien à voir avec le comportement de Laravel. C'était en fait quelque chose PHP 5.5.

C’est parce que j’ai mis à jour ma version PHP à partir de la version 5.3 et que ce problème n’a jamais eu lieu.

Dans votre fichier .ini, vous devez modifier vos paramètres OPcache. Pour moi, ces paramètres ont commencé à la ligne 1087 du fichier .ini et ressemblaient à ceci:

opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

Prenez particulièrement note du opcache.revalidate_freq=60. C'est ce qui rend réellement vos vues en cache. Si ce n'est pas le comportement souhaité, définissez la valeur sur 0 et vos vues seront mises à jour chaque fois que vous apportez une modification. Yay!

EDIT 21 AOÛT 2014

Comme mentionné par Matt ci-dessous, veillez à redémarrer votre serveur Web pour que vos modifications prennent effet après la modification de votre fichier .ini.

24
Sethen

Avec les nouvelles versions de PHP, opcache ne fonctionne pas. C'est ce que j'utilise (dans app/filters.php):

App::before(function($request)
{
    // Clear view cache in sandbox (only) with every request
    if (App::environment() == 'sandbox') {
        $cachedViewsDirectory=app('path.storage').'/views/';
        $files = glob($cachedViewsDirectory.'*');
        foreach($files as $file) {
            if(is_file($file)) {
                @unlink($file);
            }
        }
    }
});
3
Wendtly

Il est possible que ce ne soit pas du tout un problème de cache et n’ait rien à voir avec Laravel, Apache ou PHP. Si vous partagez des fichiers dans une machine virtuelle telle que Vagrant, assurez-vous que votre éditeur n'utilise pas "Atomic Saves" lors de l'écriture de fichiers.

Pour tester cela, effectuez une petite modification (un seul caractère) sur un fichier surveillé à l'aide de plusieurs éditeurs de texte différents. Les modifications enregistrées par les éditeurs qui implémentent des sauvegardes atomiques ne seront probablement pas remarquées par le système de fichiers de la machine virtuelle.

J'édite avec Sublime Text 3 sur un Mac, en sauvegardant des fichiers dans un dossier monté dans un Vagrant VM avec NFS. Les fichiers sont surveillés sur le système de fichiers local via Gulp et une actualisation du chargement du foie est demandée à l'hôte vagabond chaque fois qu'un fichier est modifié. 

La modification d'un seul caractère avec Sublime Text 3 à l'aide de la valeur par défaut atomic_save: true déclenche une modification mais ne sert pas le fichier mis à jour. Les modifications dans Vim, TextEdit, Sublime Text 2 et TextWrangler ont toutes déclenché des mises à jour et servi le contenu du fichier mis à jour. Le passage à atomic_saves: false ajoute Sublime Text 3 aux autres éditeurs, déclenche une mise à jour et sert le fichier approprié. 

Les préférences par défaut de Sublime Text 3 incluent ce commentaire:

// Save via writing to an alternate file, and then renaming it over the
// original file.
"atomic_save": true,

Le problème pourrait avoir quelque chose à voir avec les modifications écrites dans un fichier temporaire non surveillé, puis ce fichier temporaire remplaçant notre fichier surveillé. La modification se produit lorsque le fichier temporaire est écrit, pas lorsqu'il remplace le fichier que nous surveillons. Aucune mise à jour n'est déclenchée. Cela ou quelque chose avec le cache NFS ou la passerelle NFS de VirtualBox - il y a beaucoup de choses au milieu. 

De nombreuses heures ont été perdues à manipuler opcache, mods Apache et Laravel hacks avant de découvrir que ce n’était qu’un paramètre d’éditeur. 

2
joemaller

Une autre possibilité si vous utilisez un VM (comme Vagrant) et que vous partagez des fichiers de votre hôte via NFS est que NFS met en cache les temps de modification. Ceci amènerait Laravel à penser que les modèles compilés en cache sont encore frais. C’est le problème que j’avais aujourd’hui et que j’ai résolu (ainsi qu’un problème connexe gulp-watch ne remarquant pas que les fichiers sources de stylesheet et javascript étaient en train de changer) en ajoutant l’option de montage NFS lookupcache=none.

J'ai écrit à ce sujet ici: Regarder les fichiers pour vérifier les changements sur Vagrant, les temps de modification des fichiers ne sont pas mis à jour

1
tremby

J'ai eu le même problème en essayant d'éviter le cache dans l'admin, car les images téléchargées n'étaient pas rafraîchissantes. Je ne recommande pas de désactiver le cache pour toutes vos applications php, vous pouvez le faire en changeant les en-têtes. Ajouter/Modifier cette fonction dans app/filters.php:

Route::filter('after', function($response)
{
    // No caching for pages, you can do some checks before
    $response->header("Pragma", "no-cache");
    $response->header("Cache-Control", "no-store, no-cache, must-revalidate, max-age=0");
});
1
Tom Sarduy

Je devais aussi ajuster la date et l'heure.

J'utilise phpStorm pour synchroniser mes fichiers avec sftp ( car le chargement des pages du serveur sera plus rapide sur le VM ) avec VirtualBox Laravel Homestead. En plus du correctif opcache.revalidate_freq=0, je devais également m'assurer que le Homestead VM avait une date/heure antérieure à celle du système d'exploitation hôte. Sinon, le système ne pense pas que quelque chose a changé. 

Dans Ubuntu, faites Sudo dpkg-reconfigure tzdata et définissez votre fuseau horaire. Ensuite, si, par exemple, votre système d'exploitation hôte est actuellement à 11:01:00, définissez VM sur une heure légèrement plus ancienne Sudo date --set 11:00:50.

Puis Sudo nginx restart. Travaillé comme un charme! 

0
prograhammer