Améliorations des performances pour la récupération des Gravatar / Favicons & Feed

[timovn]

Dans /favatar.php on trouve ça :

require_once 'inc/boot.php';

Ceci charge toutes les dépendances de BT, exécute toutes les routines et met en mémoire l’ensemble des fonctions et variables de BT.

Il fait donc ça pour chaque Avatar présent sur la page. S’il y a 50 commentaires sous l’article, ça va en gros lancer Blogotext 50 fois de suite.

De même pour le lecteur RSS et ses favicons : je pense qu’il y a une raison qui fait que vous n’atteignez pas les perfs (comme j’ai pu lire dans les issues) que j’ai dans le lecteur RSS (CLX) : 150 flux RSS = 150 fois le lancement de tous les includes(), routines, etc.

Tout ça pour une seule fonction (create_folder()) et une seule variable (DIR_CACHE) qui ont besoin d’être inclues dans le script des favicons locaux.

Redéclarer le DIR_CACHE dans ce fichier (bien que cela fasse un chouïa moins propre) et redéclarer la fonction create_folder() qui tient en 5 lignes, et virer le include() suffirait à donner un sérieux coup de boost à l’ensemble.

Une autre solution serait de tester la présence du fichier (le favicon / l’avatar) demandé avant toute chose, et si le fichier n’est pas là, faire toutes les includes(), mais juste en dernier recours.

**

Je fais la même remarque pour le fichier /feed.php : l’intérêt d’avoir un cache de niveau 1 (purement statique) et de niveau 2 (mini DB serializé des derniers éléments), était pour éviter d’avoir à faire tous les includes PHP, qui prenaient un temps monstrueux. Avoir remis le include() tout en haut se comprend et fait plus propre, mais est très mauvais pour les perfs.

Faites le test : les includes() comptent pour l’essentiel du temps de chargement de la page, souvent bien plus de temps que les requêtes SQL, et ce n’est pas tellement une surprise.

Et sur un site le fichier feed.php sera de loin la page la plus visitée (vu que les aggrégateurs de tout le monde la chargent environ toutes les 5 minutes).

**

Optimiser le feed.php et le favatar.php (qui sont de fait les fichiers les plus demandé) revient à drastiquement décharger le serveur.

[remrem]

Salut Timo :)

Je suis d'accord avec toi, il y a sans doute un truc à faire à ce niveau. Notamment des améliorations à apporter au boot et au système de cache. Mais il y a plusieurs choses à prendre en compte, le système de VHOST et de VALIAS (VALIAS opé, VHOST en cours), la customisation des favatars et les addons...

je pense qu’il y a une raison qui fait que vous n’atteignez pas les perfs (comme j’ai pu lire dans les issues) que j’ai dans le lecteur RSS (CLX) : 150 flux RSS = 150 fois le lancement de tous les includes(), routines, etc.

Rien à voir avec favatar, le problème étant que les flux et leurs items était chargé en 1 fois. Si tu as une mise à jour des flux via cron, et qu'il y a beaucoup de flux non lus, ils sont tous chargés, pour avoir expérimenté le problème, ça me donnait une page de plus Mo à charger. Avec le système d'affichage par page, le problème a été résolu et depuis plus d'issue concernant les performances.

[B4rb3rouss]

Intéressant. Il n'empêche qu'à la fin du boot.php, tous ces appels sont très certainements abusifs dans certains cas. :

/**
 * main dependancys
 */
require_once BT_ROOT.'inc/conv.php';
require_once BT_ROOT.'inc/filesystem.php';
require_once BT_ROOT.'inc/form.php';
require_once BT_ROOT.'inc/hook.php';
require_once BT_ROOT.'inc/html.php';
require_once BT_ROOT.'inc/sqli.php';
require_once BT_ROOT.'inc/them.php';
require_once BT_ROOT.'inc/util.php';

[B4rb3rouss]

Dans le commit ci-dessus, j'ai séparé un peu les requires. favatar.php est libéré de plusieurs appels ainsi. Je n'ai pas fait trop de tri dans la partie admin, normalement nettement moins sollicitée.

[remrem]

J'ai bossé un peu dessus, et je suis parti sur des require uniquement quand nécessaire, mais c'est de l'optimisation, on verra ça dans le détail avant le freeze 3.8