Des infos

Le 1er appui sur "Recalculer cette page" provoque le rechargement du cache "page statistique", cad interrogation de la base. Egal à var_mode=calcul
Le 2ème provoque le rechargement du cache "page dynamique", cad recompilation en code php. Egal à var_mode=recalcul
Si "Recalculer cette page" est suivi d’un *, c’est que l’affichage provient du cache

NB : Il y aurait pour chaque page dans le cache un enregistrement différent par personne identifiée

Optimisation
On gagne en temps de réponse en compressant les CSS et les scripts
Mais à supprimer pendant les phases de développement.
Ces options sont dans menu "Configuration / Fonctions avancées" en bas de page
Une autre optimisation proposée dans ce menu est "Ne pas charger les scripts de barre d’outils sur l’espace public". Principe ?

Durée en cache

J’ai voulu porter la durée des pages en cache à un mois. Pour cela j’ai crée un fichier "mes_fonctions.php" sous "/squelettes" avec une ligne "define(’_DUREE_CACHE_DEFAUT’, 24*3600*30)".
Prise en compte ? Effet sur les performances ?
Après réflexion, je l’ai renommé "mes_options" sous "/config".
Mais devant l’absence d’effets, je l’ai écarté en 2017 en le rebaptisant "mes_options.test.php" !!!
Je l’ai retesté en juin 2018 : toujours sans effet ! La commande "define" serait mauvaise ? En revanche, le fichier mes_options.php est bien reconnu (une erreur de syntaxe provoque le plantage du site)

La valeur par défaut est de 86400, soit 24hx3600s (vérifié en l’affichant dans une page "test.html"

Mesures réalisées juillet 2018
Rappel de la page au bout de 16 mn : ok utilisation cache
Rappel au bout de 44 mn : recalcul
Diagnostic : sans doute cache d’environ 30 mn !

Constats au 01/06/18
L’* n’est pratiquement jamais présent. Sauf cas de lecture dans les minutes précédentes. Le cache n’est donc pratiquement pas utilisé.
Il s’étend pourtant sur un espace considérable (250 Mo au 2/06), très au dessus du volume demandé de 10Mo (dans la version 3.1)
Le vidage du cache dure au moins une demi-heure !
Mais juste après, les performances sont bien meilleures.

Actions réalisées en juin 2018
Installation du plugin Memoisation.
Mais sans résultat probant (voir réponse de Bruno)
D’où suppression

J’ai supprimé l’affichage de la noisette "Agenda". Sa complexité peut laisser espérer un gain de performance.

Pages sur les problèmes de performance

https://contrib.spip.net/Optimiser-les-performances-de-SPIP

https://contrib.spip.net/Optimisation-de-la-charge-serveur-SQL-et-var_profile

Diagnostic à transmettre a propos de la 3.1 - A revoir avec 3.2

Site Spip à l’adresse http://www.orbi.infini.fr

Les temps de réponse sont très mauvais (en général une vingtaine de secondes pour l’affichage d’une page)
Les pages ne sont pas prises dans le cache, sauf parfois, dans les toutes premières minutes après leur création (contrôle à partir de l’* suivant "Recalculer cette page")
Mais surtout, la taille du cache a tendance à se développer considérablement, bien au delà des 10 Mo attendus. Et cela semble être un facteur de la dégradation des temps de réponse. Le passage à la version 3.2 n’a rien arrangé.

J’ai tenté la mise en place d’un fichier /config/mes_options.php et du plugin "Memeisation" sans résultat. La compression des scripts et css n’a pas d’effet vraiment sensible.

Mise en place d’un identifiant spip / infini permettant de se connecter en tant qu’administrateur pour faire des tests

Réponse de Bruno Bergot

Lors de ma session de debug sur ton site j’ai remarqué une erreur avec une des feuilles de styles less. Celle-ci venait du fait que le thème utilisé par votre site n’était pas à jour, je viens de le mettre à jour et l’erreur n’est plus présente, cf le correctif associé :
https://zone.spip.org/trac/spip-zone/changeset/93701/spip-zone

A propos de la taille du cache, la valeur de 10Mo est uniquement indicative, elle peut être bien plus grande en fonction des squelettes utilisés par le site. En fait, SPIP réduit le cache à un nombre de "slots" ou répertoires, et pas à une taille donnée, d’ailleurs cette indication sera bientôt retirée de SPIP

Le plugin Memoization n’est pas exploitable chez Infini car il nécessite xcache ou memcached sur le serveur, chose qu’on ne met pas à disposition sur la plate-forme d’hébergement.

Le seul plugin qui pourrait poser problème est "Accès restreint" car il implique que le site vérifie les droits d’accès aux pages avant de les envoyer aux visiteurs, mais ça ne devrait pas ramer à ce point (pour info, j’ai désactivé ce plugin sans résultat apparent)

La première chose à faire serait de migrer ton site en PHP 7 qui
améliore grandement la rapidité de calcul des pages. On a une infra PHP 7 en test. Il suffit d’effectuer la demande pour qu’on bascule ton site vers celle-ci.

Analyse avec WebPageTest
Analyse de l’affichage de l’article1 (Activités)
http://www.orbi.infini.fr/spip.php?article1
Le mardi 10 juillet 2018 à 10h (Attention : long temps d’attente en journée, réduit à 30 secondes en pleine nuit)
Test réalisé avec IE11 depuis Paris (liaison par cable, donc temps de chargement réduit par rapport à ADSL ou 4G)
Page en principe déjà en cache
En italiques : les temps obtenus à 12h pour le 1er accès, après avoir modifié .htaccess ; pour les accès suivant, le temps n’est que de 2 à 5 sec, correspondant à l’obtention de code html

Temps de réponse pour l’obtention du 1er octet du code html : 2,2 secondes ! (5,4 secondes)
Temps de récupération et traitement des fichiers associés : 1,1 seconde
(dont 0,9 pour le javascript de ckeditor, mais en parallèle à d’autres activité pendant presque la totalité du temps)
(4,5 secondes, dont l’essentiel est l’exécution de action=cron)
Donc total chargement en : 3,3 secondes 10 secondes
Mais des tâches s’executent encore pendant : 1,9 secondes
(Rien sinon le chargement de favicon.ico)
Soit fin traitement au bout de 5,2 secondes (soit 10 secondes)
Au total 15 requêtes au serveur
Pour un transfert de 356 KB

Le test est réalisé 3 fois de suite, et il n’y a aucun gain de temps pour les 2ème et 3ème essai. Donc aucune utilisation de "cache statique". C’est déclaré en faute par le test !
Résultats détaillés :
– IP : 91.217.154.230 pour le serveur Infini
– 8KB seulement pour le fichier html
– 229.0 KB au total in compressible text, target size = 227.6 KB (donc une bonne compression en utilisant gzip)
– 123.0 KB total in images, target size = 93.9 KB (l’image présente dans le corps du texte est responsable de 92 ko)
– 9.7 KB of a possible 101.8 KB (9%) were from progressive JPEG images (une légère amélioration est possible en comprimant les images jpeg !)
– ckeditor.js représente 118KB, soit le tiers du total
– message "FAILED - (No max-age or expires)" pour toutes les requetes, donc pas d’utilisation du cache du navigateur (or des modules comme ckeditor.js, le css, ...) devraient au minimum l’être
– la tache executé après le chargement de la page est http://www.orbi.infini.fr/spip.php?action=cron. C’est elle qui demande pratiquement 1,9 seconde

J’ai vérifié qu’au bout de 15 mn, les fichiers principaux js et css provenaient bien du même cache SPIP.
Les principaux problèmes identifiés :
– le temps de réponse du serveur à la requête initiale
– l’absence d’utilisation du cache des navigateurs
– la présence du plugin ckeditor (mais pas forcément très pénalisant)

Résultats de test
Successivement les temps obtenus pour 3 appels successifs de la page "article 1"
Avec cache à 160 Mo : 9,6 - 2,0 et 1,9 sec (à 18h45 le 10/07)
Avec cache désactivé : 6,5 - 3,5 et 3,5 sec
Avec cache vidé : 2,3 - 1,8 et 1,9 sec (à 20h)
Avec cache de nouveau désactivé (?) : 8,6 - 2,2 et 1,8 sec

Actions réalisées à la suite de ces tests
1) Modification du .htaccess pour que les fichiers restent en cache dans le navigateur un certain temps.
Effet immédiat. Plus aucun temps d’attente si on revient sur une page récente. Pb : durée sans doute trop longue (surtout pour la mise à jour des pages), car la durée est donnée en mois, voire année.
A noter que la suppression de ce fichier entraîne la disparition de l’utilisation du cache navigateur

A étudier
Aucun "CDN detected"
CRON Syndic tous les 90 secondes
Et action=cron exécuté après chaque appel plutôt long
Utilisation de inclure dans une page liée à une session (optimisation de l’utilisation de cache)

Passage à PHP 7.0
Réalisé le 5/09/18 par Denis (suite à la suggestion de Bruno)
Et effectivement de meilleurs temps de réponse ont été immédiatement constatés