2013/7/29 Franck Paul <carnet.franck.paul(a)gmail.com&gt; > Il existe deux plugins de cache dispo sur DA > > http://plugins.dotaddict.org/dc2/details/staticCache > http://plugins.dotaddict.org/dc2/details/memCache > > en fait, ça configure pas du tout les headers HTTP nécessaires. Tout ce que ça fait (mais c'est déjà pas mal) c'est cacher statiquement les résultats des scripts PHP, et les rebalancer au client quand il le redemande, ce qui économise de la ressource serveur. Les headers HTTP de cache dont je parle, ça peut provoquer 2 choses: * le navigateur ne va même pas aller chercher une mise à jour s'il pense que la ressource est encore à jour * s'il pense qu'elle doit être vérifiée (on dit "revalidée"), il va faire une requête conditionnelle, et le serveur web va vérifier si la ressource est à jour (il va juste renvoyer un 304 sans aucune autre information, notamment aucun payload, ce qui dit au navigateur de prendre la ressource dans son cache), ou bien pas à jour (dans ce cas il renvoie un 200 avec toute la page, comme si la requête n'était pas conditionnelle) ça économise encore plus de ressource serveur, mais aussi de la ressource réseau, et en plus ça va plus vite pour le client. évidemment, dans le cas d'une page dynamique générée par PHP, c'est au logiciel de gérer tout ça, et c'est loin d'être trivial, ya un peu de boulot :) -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

2013/7/29 Franck Paul <carnet.franck.paul(a)gmail.com&gt; > Il existe deux plugins de cache dispo sur DA > > http://plugins.dotaddict.org/dc2/details/staticCache > http://plugins.dotaddict.org/dc2/details/memCache en fait, ça configure pas du tout les headers HTTP nécessaires. Tout ce que ça fait (mais c'est déjà pas mal) c'est cacher statiquement les résultats des scripts PHP, et les rebalancer au client quand il le redemande, ce qui économise de la ressource serveur. Les headers HTTP de cache dont je parle, ça peut provoquer 2 choses: * le navigateur ne va même pas aller chercher une mise à jour s'il pense que la ressource est encore à jour * s'il pense qu'elle doit être vérifiée (on dit "revalidée"), il va faire une requête conditionnelle, et le serveur web va vérifier si la ressource est à jour (il va juste renvoyer un 304 sans aucune autre information, notamment aucun payload, ce qui dit au navigateur de prendre la ressource dans son cache), ou bien pas à jour (dans ce cas il renvoie un 200 avec toute la page, comme si la requête n'était pas conditionnelle) ça économise encore plus de ressource serveur, mais aussi de la ressource réseau, et en plus ça va plus vite pour le client. évidemment, dans le cas d'une page dynamique générée par PHP, c'est au logiciel de gérer tout ça, et c'est loin d'être trivial, ya un peu de boulot :) -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le cache HTTP est géré, et plutôt pas trop mal géré pour du dynamique. Ensuite, pour aller plus loin, il y a les plugins de cache cités par Franck qui, même sans être la panacée, s'avèrent être rudement efficaces une fois bien configurés (et bons également pour les ressources serveur). Il y a une faiblesse dans le design de DC pour gérer facilement et finement un cache statique. Ça demanderait un gros travail de fond qui sera sans doute fait un jour. Mais pour le cache HTTP, lis bien le code et tu verras que sa gestion est plus que correcte. Le 29 juil. 2013 à 00:31, Julien Wajsberg <felash(a)gmail.com&gt; a écrit : 2013/7/29 Franck Paul <carnet.franck.paul(a)gmail.com&gt; > Il existe deux plugins de cache dispo sur DA > > http://plugins.dotaddict.org/dc2/details/staticCache > http://plugins.dotaddict.org/dc2/details/memCache > > en fait, ça configure pas du tout les headers HTTP nécessaires. Tout ce que ça fait (mais c'est déjà pas mal) c'est cacher statiquement les résultats des scripts PHP, et les rebalancer au client quand il le redemande, ce qui économise de la ressource serveur. Les headers HTTP de cache dont je parle, ça peut provoquer 2 choses: * le navigateur ne va même pas aller chercher une mise à jour s'il pense que la ressource est encore à jour * s'il pense qu'elle doit être vérifiée (on dit "revalidée"), il va faire une requête conditionnelle, et le serveur web va vérifier si la ressource est à jour (il va juste renvoyer un 304 sans aucune autre information, notamment aucun payload, ce qui dit au navigateur de prendre la ressource dans son cache), ou bien pas à jour (dans ce cas il renvoie un 200 avec toute la page, comme si la requête n'était pas conditionnelle) ça économise encore plus de ressource serveur, mais aussi de la ressource réseau, et en plus ça va plus vite pour le client. évidemment, dans le cas d'une page dynamique générée par PHP, c'est au logiciel de gérer tout ça, et c'est loin d'être trivial, ya un peu de boulot :) -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Perso j'ai configuré ça dans le .htaccess de mon installation : # COMPRESS TEXT, HTML, JAVASCRIPT, CSS, XML <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE text/x-component AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript </IfModule> # Turn on Expires and set default expires to 1 day ExpiresActive On # ExpiresActive Off ExpiresDefault "access plus 1 day" # Set up caching on font files for 1 month <FilesMatch "\.(eot|svg|ttf|woff)$"> ExpiresDefault "access plus 1 month" Header append Cache-Control "public" </FilesMatch> # Set up caching on media files for 1 week <FilesMatch "\.(ico|gif|jpg|jpeg|png|flv|pdf|swf|mov|mp3|wmv|ppt|m4v|avi)$"> ExpiresDefault "access plus 1 week" Header append Cache-Control "public" </FilesMatch> # Set up 48 Hour caching on commonly updated files <FilesMatch "\.(txt|html|js|css)$"> ExpiresDefault "access plus 2 days" Header append Cache-Control "public" </FilesMatch> # Set up 1 Hour caching on frequently updated files <FilesMatch "\.(xml|xsl)$"> ExpiresDefault "access plus 1 hour" Header append Cache-Control "public" </FilesMatch>

Absolument : nous avons fait l’impasse sur Expires puisque trop « primaire » dans le contexte dynamique.**** ** ** Je ne suis évidemment pas du tout contre l’idée de fournir un exemple de configuration Expires, au contraire. Mais je ne sais pas sous quelle forme cela serait le plus judicieux (cas de serveurs Nginx, IIS, etc. ou d’apache sans gestion des .htaccess ou aux .htaccess aux « pouvoirs » limités).**** ** ** Et comme je le disais, et j’ai vu qu’il y avait déjà un ticket à ce sujet ( http://dev.dotclear.org/2.0/ticket/1035), le point délicat reste le mécanisme interne de détermination de la fraicheur des contenus, qui n’est pas des plus « smart ». :-)**** ** ** ** ** ** ** *De :* dev-bounces(a)list.dotclear.org [mailto:dev-bounces@list.dotclear.org] *De la part de* Julien Wajsberg *Envoyé :* lundi 29 juillet 2013 11:44 *À :* dev(a)list.dotclear.org *Objet :* Re: [Dotclear Dev] Dotclear et le Cache HTTP (Was: plugin postsStats)**** ** ** je viens de vérifier, et les headers If-None-Match et If-Modified-Since sont en effet gérés, chouette, my bad, mea culpa, tout ça :)**** en revanche, on gère pas du tout les Expires, ça pourrait valoir le coup d'avoir ça dans le .htaccess par défaut pour les ressources statiques ?*** * ** ** 2013/7/29 Pep <pep(a)callmepep.org&gt;**** Le cache HTTP est géré, et plutôt pas trop mal géré pour du dynamique.**** ** ** Ensuite, pour aller plus loin, il y a les plugins de cache cités par Franck qui, même sans être la panacée, s'avèrent être rudement efficaces une fois bien configurés (et bons également pour les ressources serveur).* *** ** ** Il y a une faiblesse dans le design de DC pour gérer facilement et finement un cache statique. Ça demanderait un gros travail de fond qui sera sans doute fait un jour.**** ** ** Mais pour le cache HTTP, lis bien le code et tu verras que sa gestion est plus que correcte.**** ** ** ** ** Le 29 juil. 2013 à 00:31, Julien Wajsberg <felash(a)gmail.com&gt; a écrit :**** ** ** 2013/7/29 Franck Paul <carnet.franck.paul(a)gmail.com&gt;**** Il existe deux plugins de cache dispo sur DA http://plugins.dotaddict.org/dc2/details/staticCache http://plugins.dotaddict.org/dc2/details/memCache**** ** ** ** ** en fait, ça configure pas du tout les headers HTTP nécessaires. Tout ce que ça fait (mais c'est déjà pas mal) c'est cacher statiquement les résultats des scripts PHP, et les rebalancer au client quand il le redemande, ce qui économise de la ressource serveur.**** Les headers HTTP de cache dont je parle, ça peut provoquer 2 choses:**** * le navigateur ne va même pas aller chercher une mise à jour s'il pense que la ressource est encore à jour**** * s'il pense qu'elle doit être vérifiée (on dit "revalidée"), il va faire une requête conditionnelle, et le serveur web va vérifier si la ressource est à jour (il va juste renvoyer un 304 sans aucune autre information, notamment aucun payload, ce qui dit au navigateur de prendre la ressource dans son cache), ou bien pas à jour (dans ce cas il renvoie un 200 avec toute la page, comme si la requête n'était pas conditionnelle)**** ça économise encore plus de ressource serveur, mais aussi de la ressource réseau, et en plus ça va plus vite pour le client.**** ** ** évidemment, dans le cas d'une page dynamique générée par PHP, c'est au logiciel de gérer tout ça, et c'est loin d'être trivial, ya un peu de boulot :)**** -- **** Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev**** -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev**** ** ** -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Je vois que pep connait cette partie de Dotclear :-) Le cache dans Dotcelar est plutôt bien géré par rapport aux contraintes, en effet pour avoir testé staticCache et memCache j'en suis revenu à la gestion de base de Dotclear. En effet ces plugins ont des effets néfastes sur pal mal de widgets qui du coup ne sont plus relu/régénéré... Mais pour un blog standard c'est pas mal Un ticket trainait pour affiner triggerBlog() mais sous réserve que quelqu'un par la suite ponde un plugin qui sache s'en servir, vu le nombre de dev d'il y a un mois c'était pas l'urgence... Pour remplir un .htaccess dans la distribution Dotclear, de plus en plugs de gens utilise nginx alors je sais pas trop si il faut compter sur ce fichier... Le 29/07/2013 11:56, Pep a écrit : Absolument : nous avons fait l’impasse sur Expires puisque trop « primaire » dans le contexte dynamique.**** ** ** Je ne suis évidemment pas du tout contre l’idée de fournir un exemple de configuration Expires, au contraire. Mais je ne sais pas sous quelle forme cela serait le plus judicieux (cas de serveurs Nginx, IIS, etc. ou d’apache sans gestion des .htaccess ou aux .htaccess aux « pouvoirs » limités).**** ** ** Et comme je le disais, et j’ai vu qu’il y avait déjà un ticket à ce sujet ( http://dev.dotclear.org/2.0/ticket/1035), le point délicat reste le mécanisme interne de détermination de la fraicheur des contenus, qui n’est pas des plus « smart ». :-)**** ** ** ** ** ** ** *De :* dev-bounces(a)list.dotclear.org [mailto:dev-bounces@list.dotclear.org<dev-bounces@list.dotclear.org>] *De la part de* Julien Wajsberg *Envoyé :* lundi 29 juillet 2013 11:44 *À :* dev(a)list.dotclear.org *Objet :* Re: [Dotclear Dev] Dotclear et le Cache HTTP (Was: plugin postsStats)**** ** ** je viens de vérifier, et les headers If-None-Match et If-Modified-Since sont en effet gérés, chouette, my bad, mea culpa, tout ça :)**** en revanche, on gère pas du tout les Expires, ça pourrait valoir le coup d'avoir ça dans le .htaccess par défaut pour les ressources statiques ?*** * ** ** 2013/7/29 Pep <pep(a)callmepep.org&gt;**** Le cache HTTP est géré, et plutôt pas trop mal géré pour du dynamique.**** ** ** Ensuite, pour aller plus loin, il y a les plugins de cache cités par Franck qui, même sans être la panacée, s'avèrent être rudement efficaces une fois bien configurés (et bons également pour les ressources serveur).* *** ** ** Il y a une faiblesse dans le design de DC pour gérer facilement et finement un cache statique. Ça demanderait un gros travail de fond qui sera sans doute fait un jour.**** ** ** Mais pour le cache HTTP, lis bien le code et tu verras que sa gestion est plus que correcte.**** ** ** ** ** -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev