La config que j'ai proposé est orientée côté serveur.
Elle prend non seulement en compte les scripts PHP, mais aussi tous les fichiers statiques images, pages HTML, feuilles CSS, scripts Javascript
Dommage que la vidéo ne finisse pas en parlant de la date d'expiration qui évite de solliciter le serveur pendant un certain pour savoir si quelque chose a changé.
Peut-être dans une porchaine vidéo.
Merci pour le tips de l'inspecteur de contenu, c'est ce sur quoi je m'appuyais déjà pour mes tests.
La semaine dernière je constatais temps de chargement sur les objets sur mon site de test malgré les expires, mais tout est OK sur mon site de prod apparemment.
Mettons donc ça à l'écart.
De mon côté j'utilise aussi des règles d'expiration. Je ne les avais pas incluses dans le template afin de garder le template minimaliste (les plus connaisseurs pouvant le changer au besoin).
Mais si tu estimes que cela vaut vraiment le coup d'avoir une politique de cache par défaut, on va l'ajouter. Je te propose une règle un peu plus scalpel pour paramétrer les expires :
Je compte déjà des absents dans la liste des extensions très populaires :
pdf, ico, txt, html, ....
Je suis plus enclin à utiliser des règles plus restrictives basées sur des dossiers, quitte à rajouter quelques règles plus précises pour quelques cas particuliers.
Les règles basées sur le nom exact des répertoires sont plus rapides que les régles à base d'expressions régulières.
Je désapprouve totalement ce mélange de fichiers statiques javascript et autres avec des scripts php dans le dossier core/lib de PluXml.
Cela ne facilite pas la gestion du serveur et ce n'est pas courant.
En toute modestie, je préfère les miennes.
Je pense qu'il faut rajouter ces règles au template, sinon les gens n'auront pas conscience de leurs existences. Des docs en français sur Nginx ne sont pas très nombreuses.
On peut les mettre en commentaires pour éviter de perturber les gens.
J'ai testé ta configuration. Ce qui me faisait peur c'était le risque de cacher du contenu dynamique dans des plugins tel que le plxCapchaImage.
Mais à priori l'expire n'est pas appliqué au capcha.php. Nous nous restera donc à voir si des utilisateurs constatent des effets de bord.
J'ai donc ajouté tes directives de cache dans les templates de configuration par défaut et pas en commentaire. Après tout c'est une grande amélioration.
Ceci dit je les ai tout de même adaptés sous forme de regex afin de préserver la lisibilité de la configuration. Même si les regex sont plus coûteuses que des expressions simples, elles doivent rester négligeables sur le temps traitement.
Mon avis perso:
J'aurais laissé chaque config séparée pour 3 raisons:
- on gagne un peu en vitesse
- dès qu'on parle expressions régulières, les rangs des troupes s'éclaircissent. Il y a qu'à regarder dans PluXml pour avoir un état de l'Art.
- data, le fameux de dossier de données, apparait plusieurs fois dans la config. L'idée serait de remplacer par une constante à déclarer au début. Il serait alors aisé de renommer ce dossier sans risque. Par expèrience, quand on commence à faire des répétitions, les modifs deviennent chronophages après coup. D'où ma tendance à paramètrer "à mort" en déclarant des constantes. A priori cela semble possible avec nginx.conf mais je n'ai pas encore testé.
Prochaine étape : avoir un fichier de config intégré dans le dossier readme de la prochaine version de PluXml.
Il y a de plus en plus de gens qui s'installent chez eux un petit serveur avec un Raspberry Pi et en général on préconise Nginx à la place d'Apache2.
Puisque tu es dans la mise à jour, ce point sur le wiki n'est pas correct :
[== This is just a plain text ==]
Le fichier doit être placé dans l'un de ces deux emplacements :
/etc/nginx/conf.d/
/etc/nginx/sites-enabled/
Sous Debian et Ubuntu, les fichiers de config sont dans le dossier /etc/nginx/sites-available, comme pour Apache2. Je suppose que dans les autres distribs LInux, c'est la même chose.
La recette pour réussir sa config est plutôt celle-ci :
[== bash ==]
$ cd /etc/nginx/sites-enabled/
$ sudo nano ../sites-available/pluxml
# copier/coller dans l'éditeur Nano une des configs ci-après
# et quitter en tapant Ctrl-X en acceptant la sauvegarde du fichier
$ sudo rm -f default
$ sudo ln -s ../sites-available/pluxml default
$ sudo systemctl restart nginx
$ cd $OLDPWD
# Penser à utiliser la touche tabulation pour la complétion en ligne de commande
Cela mériterait un petit script bash dans la prochaine version de PluXml pour automatiser le truc ]:D
Pour info Nginx limite la taille des téléversements (upload) à 1 méga-octet.
Au delà de cette limite, on se prend une erreur 413.
Cela peut être gênant si on veut téléverser un plugin avec kzUploader sur un site web.
Il faut ajouter la directive client_max_body_size dans le fichier de config du site pour repousser cette limite.
J'ai fait la modif sur le wiki.
Autre petite modif.
Comme l'archive de PluXml a un dossier PluXml, j'ai réglé la directive root à : /var/www/PluXml.
Il y a également un petit commentaire pour ceux qui utiliser Alpinelinux.
Réponses
La config que j'ai proposé est orientée côté serveur.
Elle prend non seulement en compte les scripts PHP, mais aussi tous les fichiers statiques images, pages HTML, feuilles CSS, scripts Javascript
Dommage que la vidéo ne finisse pas en parlant de la date d'expiration qui évite de solliciter le serveur pendant un certain pour savoir si quelque chose a changé.
Peut-être dans une porchaine vidéo.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Merci pour le tips de l'inspecteur de contenu, c'est ce sur quoi je m'appuyais déjà pour mes tests.
La semaine dernière je constatais temps de chargement sur les objets sur mon site de test malgré les expires, mais tout est OK sur mon site de prod apparemment.
Mettons donc ça à l'écart.
De mon côté j'utilise aussi des règles d'expiration. Je ne les avais pas incluses dans le template afin de garder le template minimaliste (les plus connaisseurs pouvant le changer au besoin).
Mais si tu estimes que cela vaut vraiment le coup d'avoir une politique de cache par défaut, on va l'ajouter. Je te propose une règle un peu plus scalpel pour paramétrer les expires :
C'est un peu plus concis et ça ne cible vraiment que le contenu statique. Qu'en penses-tu ?
Je compte déjà des absents dans la liste des extensions très populaires :
pdf, ico, txt, html, ....
Je suis plus enclin à utiliser des règles plus restrictives basées sur des dossiers, quitte à rajouter quelques règles plus précises pour quelques cas particuliers.
Les règles basées sur le nom exact des répertoires sont plus rapides que les régles à base d'expressions régulières.
Je désapprouve totalement ce mélange de fichiers statiques javascript et autres avec des scripts php dans le dossier core/lib de PluXml.
Cela ne facilite pas la gestion du serveur et ce n'est pas courant.
En toute modestie, je préfère les miennes.
Je pense qu'il faut rajouter ces règles au template, sinon les gens n'auront pas conscience de leurs existences. Des docs en français sur Nginx ne sont pas très nombreuses.
On peut les mettre en commentaires pour éviter de perturber les gens.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
J'ai testé ta configuration. Ce qui me faisait peur c'était le risque de cacher du contenu dynamique dans des plugins tel que le plxCapchaImage.
Mais à priori l'expire n'est pas appliqué au capcha.php. Nous nous restera donc à voir si des utilisateurs constatent des effets de bord.
J'ai donc ajouté tes directives de cache dans les templates de configuration par défaut et pas en commentaire. Après tout c'est une grande amélioration.
Ceci dit je les ai tout de même adaptés sous forme de regex afin de préserver la lisibilité de la configuration. Même si les regex sont plus coûteuses que des expressions simples, elles doivent rester négligeables sur le temps traitement.
J'aurais laissé chaque config séparée pour 3 raisons:
- on gagne un peu en vitesse
- dès qu'on parle expressions régulières, les rangs des troupes s'éclaircissent. Il y a qu'à regarder dans PluXml pour avoir un état de l'Art.
- data, le fameux de dossier de données, apparait plusieurs fois dans la config. L'idée serait de remplacer par une constante à déclarer au début. Il serait alors aisé de renommer ce dossier sans risque. Par expèrience, quand on commence à faire des répétitions, les modifs deviennent chronophages après coup. D'où ma tendance à paramètrer "à mort" en déclarant des constantes. A priori cela semble possible avec nginx.conf mais je n'ai pas encore testé.
Prochaine étape : avoir un fichier de config intégré dans le dossier readme de la prochaine version de PluXml.
Il y a de plus en plus de gens qui s'installent chez eux un petit serveur avec un Raspberry Pi et en général on préconise Nginx à la place d'Apache2.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
J'ai intégré tes suggestions de caching.
Puisque tu es dans la mise à jour, ce point sur le wiki n'est pas correct : Sous Debian et Ubuntu, les fichiers de config sont dans le dossier /etc/nginx/sites-available, comme pour Apache2. Je suppose que dans les autres distribs LInux, c'est la même chose.
La recette pour réussir sa config est plutôt celle-ci : Cela mériterait un petit script bash dans la prochaine version de PluXml pour automatiser le truc ]:D
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Bonjour,
Pour info Nginx limite la taille des téléversements (upload) à 1 méga-octet.
Au delà de cette limite, on se prend une erreur 413.
Cela peut être gênant si on veut téléverser un plugin avec kzUploader sur un site web.
Il faut ajouter la directive client_max_body_size dans le fichier de config du site pour repousser cette limite.
J'ai fait la modif sur le wiki.
Autre petite modif.
Comme l'archive de PluXml a un dossier PluXml, j'ai réglé la directive root à : /var/www/PluXml.
Il y a également un petit commentaire pour ceux qui utiliser Alpinelinux.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2