Optimiser Typo3, une tentative de synthèse... [MàJ] : un petit mot sur le cHash Options

[duch]

Je ne sais pas si vous l'avez remarqué, mais à chaque fois qu'il y a une conférence sur l'optimisation de Typo3 quelque part, elle dure 45 minutes sur Apache, 2 minutes sur MySQL et... 30s sur Typo3 (j'éxagère à peine).

Je ne doute pas que les optimisations d'Apache et de MySQL apportent beaucoup aux performances d'un site mais cela n'est aucunement spécifique à Typo3, et je me demande souvent ce que fait le mot Typo3 dans le titre de l'article ou de la conf (c'est si vendeur que ça?).
Il y a pourtant de nombreuses optimisations possibles dans la réalisation d'un projet Typo3 qui sont rarement abordées et c'est bien dommage... il y aurait pourtant énormément de choses à dire...

Mais comme je suis gentil et que je ne vais pas vous laisser sur votre faim, en voici quelques unes (liste non exhaustive) glanées sur le web, dans les conf de l'uni de cette année et également dans mon expérience personnelle (car oui, j'ai commis certaines des erreurs mentionnées ci-dessous et c'est comme ça que j'ai appris).


Changelog de ce post :

- ajout d'une explication sur le paramètre cHash
- ajout d'une mention sur COA_GO
- ajout de la section "Attention aux champs starttime et endtime"
- suppression de l'alerte sur formidable, ajout d'une section de mise en garde sur la version utilisée
- ajout de la section "les USER_INT et le cache"
- ajout d'une grosse alerte sur ameos_formidable
- ajout de la référence à YSlow, ajout de la section mod_deflate
- version initiale



1 - Les caches
Avant même de penser à optimiser le temps de rendu de son site, il faut penser à une chose toute simple : aucun serveur n'est moins chargé que celui qui n'est pas utilisé.
Ça veut dire quoi? tout simplement que la première des optimisations est d'utiliser vos ressources avec parcimonie et donc d'utiliser les différents niveaux de cache (qui sont nombreux vous allez le voir) :

- le cache côté client :
Une fois en production, de nombreux fichiers changent peu (js, css, images de templates...), pensez donc à activer le cache côté client pour ces fichiers en mettant ceci dans votre fichier .htaccess:

Code

# cacher les fichier .css et .js mais vérifier tout de même si ils n'ont pas changé (le fameux must-revalidate)
# alternativement, si il ne changent vraiment plus, vous pouvez virer le must-revalidate
<FilesMatch "\.(js|css)$">
    ExpiresActive On
    ExpiresDefault "access plus 10 days"
    Header append Cache-Control "public, must-revalidate"
#    Header append Cache-Control "public"
    FileETag MTime Size
</FilesMatch>

# cacher les images, aucun risque pour les images générées par Typo3 car elles ont toujours un nom unique en fonction de leur paramètres.
# ça vous donnera un grand bol d'air sur les images de template et on peux d'ailleurs imaginer un .htacces spécifique pour le dossier fileadmin/templates
<FilesMatch "\.(png|gif|jpe?g|png)$">
    ExpiresActive On
    ExpiresDefault "access plus 10 days"
    Header append Cache-Control "public"
    FileETag MTime Size
</FilesMatch>

- le cache en file-system :
Même si le cache de Typo3 est assez efficace, il implique tout de même de lancer le moteur PHP, de faire des connexions à la base, de vérifier la session de l'utlisateur, autant d'opérations assez coûteuses (et j'en passe).
Si votre site comporte de nombreuses pages de contenu simple sans interaction, utilisez l'extension nc_staticfilecache, les pages seront servies par Apache seul sans recours à PHP.
Le gain annoncé dans la doc de cette extension n'est pas une légende.
Astuce : comment faire si 95% de votre page peut-être mise en cache mais pas l'intégralité car vous avez par exemple une loginbox sur toutes les pages? Réponse simple : pensez à l'ajax avec une page de login en alternative pour les gens dont le javascript est désactivé. Ainsi, vous pourrez servir une page 100% mise en cache et seul la zone de login changera en ajax.

- le cache de Typo3 :
C'est une évidence, mais il est bon de le rappeller : si le cache de Typo3 est désactivé les performances chuteront de manière significatives.
Évitez-donc d'utiliser config.no_cache = 1 dans vos typoscripts
Comme le rapelle Dmitry, traquez sans relâches les extensions codées avec les pieds qui désactivent le cache malgré vous, faites une recherche dans le code de l'extension sur "set_no_cache", si vous le trouvez, changez d'extension.

- les USER_INT et le cache Une petite pépite que j'avais oublié (j'en retrouve au fur et à mesure)
Il arrive souvent qu'on utilise le type de plugin USER_INT pour des remontées automatiques de contenu afin que le contenu soit toujours à jour.
La question à se poser est "ai-je vraiment besoin que tel contenu soit toujours vraiment à jour?" si la réponse est non, bien évidemment on peut utiliser le type USER mais là bien entendu on est contraint par la durée de vie de la page elle-même dans le cache (24h par défaut). Comment faire si on souhaite que notre contenu soit mis à jour toutes les 10 minutes? La solution du bourrin : réduire la durée de vie de la page à 10 minutes, mais là, les perfs peuvent s'en ressentir.
Une solution plus élégante consiste à utiliser le système de cache de Typo3 dans notre propre extension. C'est faisable en quelques étapes simple :

Code

// je génère un md5 de la conf de mon plugin :
$hash = md5(serialize($conf));
// je vérifie si ce md5 n'est pas trouvé dans la table cache_hash avec une durée de vie inférieure à 10 minutes :
$cachedContent = $GLOBALS['TSFE']->sys_page->getHash($hash, (10*60))
// si il est trouvé, je renvois direct le contenu que je trouve
if ($cachedContent)    {
    $cachedContent = unserialize($cachedContent);
    return $cachedContent['content'];
}
// si il n'est pas trouvé, je fait mes traitements et à la fin, je stocke le résultat dans la table de cache avant de le retourner
$GLOBALS['TSFE']->sys_page->storeHash(
    $hash,
    serialize(
        array(
            'content' => $content
        )
    ),
    'tx_monextension'
);

return $content;

Edit : c'est exactement ce que fait l'extension COA_GO mentionnée par Rakel, donc allez y jetter un oeil : http://forge.typo3.org/wiki/extension-coago/

- Utiliser le paramètre cHash :
Prenons un cas typique : vous avez un plugin qui affiche une liste d'enregistrements et une vue détaillée de chaque enregistrement. Si vous faites un plugin de type USER (mis en cache), vous aurez la surprise de constater que toutes les vues détaillées affichent le même enregistrement (celui qui a été mis en cache le premier). C'est logique puisque Typo3 ne traite que 2 paramètres dans l'URL pour vérifier l'unicité d'une page, id et type (pour des raisons de sécurité que je ne développerais pas), et donc dans votre cas, votre paramètre tx_monext[uid] n'est pas considéré par Typo3 comme pouvant changer l'aspect de la page, il renvoit donc la première page trouvée dans le cache qui correspond à id=x.
Une solution simple est d'utiliser un plugin de type USER_INT qui ne sera pas mis en cache, mais cela n'est pas forcément optimal.
C'est là qu'intervient le si mystérieux paramètre cHash. Il permet à Typo3 de pouvoir différencier des "versions" d'une même page en prenant en compte les paramètres supplémentaires que vous pouvez passer au moment de la génération de l'url le tout en toute sécurité. Ainsi, chacune de vos vues détaillées sera mise en cache avec son contenu propre dépendant des paramètres de l'URL, bref, le meilleur des mondes au niveau perfs.

Pour mettre en place le cHash, c'est assez simple :
- au moment de créer le lien vers votre vue détaillée, il suffit d'utiliser le paramètre useCacheHash=true de l'objet typolink (que ce soit en typoscript ou dans le code de votre plugin en utilisant la méthode tslib_cObj->typoLink())
- ajouter ceci au début de votre méthode main() : var $pi_checkCHash = true; (sans rentrer dans les détails, ça vous évitera des mauvaises surprises au cas où quelqu'un s'amuse à passer un cHash vide dans une URL).

Un petit bémol : Je n'ai jamais eu le cas, mais il est en théorie possible de bourrer vous même la table de cache si vous utilisez le cHash sur une page dont les combinaisons de paramètres peuvent générer de nombreuses versions, genre, vous avez 1000 news et 3 ou 4 paramètres qui peuvent changer le type d'affichage, ça peut engendrer quelques milliers de pages en cache. Ça n'empêchera pas votre site de tourner mais la structure de la table cache_hash n'étant pas optimale (il ne peut pas y avoir d'index) ça pourrait en théorie ralentir tout votre site. Donc à utiliser avec discernement.
Un exemple d'endroit où il ne faut surtout pas l'utiliser : un moteur de recherche dont la page des résultats génèrerait en bonus des URLs dynamiques genre /recherche/mon-mot.html que l'utilisateur pourrait bookmarker. Ça semble une bonne idée de mettre la page mon-mot.html en cache car ça éviterait de refaire la requête, mais je vous laisse imaginer ce qu'il se passerait si un pirate vous bombardait de requêtes pleines de mots aléatoires, la table de cache serait saturée en moins de 2...

si c'est pas très clair, je vous invite à lire cet article : http://typo3.org/development/articles/the-...f-chash/french/

- le cache de MySQL :
MySQL intègre également un système de cache pour les requêtes couramment appellées. Si votre serveur comporte suffisament de RAM, augmenter cette valeur peut apporter des gains très significatifs.
Quelques valeurs à vérifier dans my.cnf :

Code

query_cache_size # taille du cache
query_cache_type # 0 ou OFF désactive complètement le cache (pas bon), 1 ou ON (bon)

Vérifier que votre cache est bien réglé :

Code

SHOW VARIABLES LIKE '%query_cache%'

Vérifier l'étât de votre cache :

Code

SHOW STATUS LIKE '%Qcache%'

> Si vous avez beaucoup de Qcache_lowmem_prunes et que vous avez de la RAM disponible, essayer d'augmenter query_cache_size (sans faire exploser votre serveur bien sûr)



2 - Les paramètres de localconf.php (tirés en partie de la conf de Dmitry et testés)

- no_pconnect : soyons clair, ce paramètre n'apporte aucun gain de performance, mais il évite des fuites de mémoires dans le cas où des résultats de requêtes seraient mal libérés et donc une dégradation possible des performances. donc dans la plupart des cas, OUI, il faut le passer à 1.
Par contre, si vos serveurs apache et MySQL sont sur 2 machines différentes, les connexions persistentes peuvent dans certains cas apporter un gain de performance (si le réseau est saturé par exemple) donc là, il faut tester selon votre config et si vous êtes sûrs que votre application ne présente pas de fuites de mémoire vous pouvez le laisser à 0.

- t3lib_cs_convMethod et t3lib_cs_utils : la valeur mbstring est effectivement la plus rapide, mais il est infiniment plus rapide de créer votre site dès le début en UTF-8, cela évitera des conversions inutiles.

- enable_DLOG : une fois votre site en production, n'oubliez pas de désactiver les logs, même si aucune extension de log n'est installée cela appelle des méthodes en plus.

- sqlDebug et displayErrors, utiles en développement ces valeurs devraient être à 0 en production (c'est la valeur par défaut mais on ne sait jamais)

- la liste des extensions : bien sûr il faut désactiver les extensions non utilisées dans votre projet, mais comme je suis un cinglé notoire, je pousse le vice encore plus loin en désactivant les extensions qui ne devraient pas se retrouver (à mon humble avis) en production comme par exemple tstemplate,tstemplate_info,tstemplate_objbrowser,install,tstemplate_ceditor,tste
mplate_analyzer,tsconfig_help,phpmyadmin,kickstarter,devlog,llxmltranslate

NB : Oui, je désactive les modules typoscript car tous mes typoscript sont stockés dans des fichiers externes donc je n'en ai pas besoin
NB2 : Pour être honnête l'impact est plus intéressant en terme de sécurité qu'en terme de performances mais j'allais quand même pas faire un article juste là dessus


3 - Optimisez les index de Typo3 et des extensions

Vaste sujet que celui-ci, ajouter des index peut engendrer des gains extrêmement importants mais cela peut également diminuer les performances dans certains cas car si un index atteint un poids trop important il n'est plus utilisé par MySQL.
Il n'y a donc pas de règle stricte là dessus, il faut analyser les requêtes effectuées par le coeur et les extensions et ajouter des index sur les tables un par un afin de vérifier si il y a un impact positif sur les performances.
MySQL travaille extrêmement bien avec des index sur des champs de type numériques, le gain est faible voire nul sur des champs de type texte ou blob.
Lire : http://wiki.typo3.org/index.php/Performanc...xes_effectively

Un petit exemple :
J'ai repris un site il y a 3 ans sur lequel certaines requêtes étaient extrêmement lentes, en modifiant le type d'un champ de blob à int (on se demande pourquoi c'était un blob alors qu'il ne stockait que des int, merci le kickstarter...) et en y ajoutant un index, les requêtes allaient 100 fois plus vite.


4 - Les pièges à éviter dans vos extensions

- évitez d'utiliser la méthode substituteMarkerArrayCached (http://dmitry-dulepov.com/article/why-substitutemarkerarraycached-is-bad.html)

- attention aux pièges du kickstarter, c'est pratique mais la structure de base de données générée est rarement optimale (notamment au niveau des index, voir l'exemple ci-dessus)

- optimisez vos requêtes : comme l'a rappellé Nicolas dans sa conf, rien ne pourra vous sauvez si vos requêtes sont mal construites, donc testez les et re-testez les.

- utilisez des tables MM (quand c'est nécessaire) : le kickstarter propose 2 types de liaisons, les liaisons simples où la liaison est stockée sous forme d'une liste séparées par des virgules et une "vraie" liaison de type MM.
La tendance est à dire qu'il faut utiliser des liaisons MM partout, ce qui est une approche totalement erronée car dans de nombreux cas une liaison simple est bien plus rapide.
Pour faire simple, on pourrait dire que si votre champ peut être lié à plusieurs enregistrements d'une autre table il est souvent plus rapide d'utiliser une liaison MM (et encore c'est à vérifier dans la pratique pour votre cas). Si votre enregistrement ne peut-être lié qu'à UN SEUL enregistrement d'une autre table, une liaison simple sera (presque?) toujours plus rapide (rien ne vous empêche de construire votre requête avec un JOIN dans ce cas là également) car pas la peine dans ce cas de faire une requête tordue pour gêrer la présence de la virgule (puisqu'il n'y a qu'un élément), comme d'habitude, il faut réfléchir et faire des tests.

- utilisez la fonction eID pour vos requêtes AJAX (quand c'est nécessaire) : j'ai souvent vu des requêtes ajax qui se faisaient sur une page standard de Typo3 dont le typeNum particulier faisait qu'elle renvoyait un XML, un bout de HTML ou une chaine JSON. En terme de temps de réponse c'est une catastrophe car pour générer une telle page, il va falloir charger intégralement Typo3 (et c'est pas léger) alors que souvent, on a juste besoin de faire une petite requête dans une base pour renvoyer un petit rien du tout.
Depuis la version 4.0, Typo3 intègre un mécanisme nommé eID, qui permet d'accéder aux infos de votre site sans charger l'intégralité de Typo3, en terme de perfs et de charge serveur, c'est un gros plus (Google : "Typo3 eid")

/!\ Attention : j'ai vu sur le forum que ce conseil avait été parfois mal interprété. l'eID n'est interessant que dans le cas où le contenu à renvoyer est très simple et peut-être généré sans l'aide du moteur de rendu de Typo3 (genre, une requête SQL, une boucle en PHP et on crache le contenu). Dans le cas contraire, et comme le faisait remarquer Popy, cela peut entrainer une dégradation des performances (car le cache n'est pas géré par eID), donc encore une fois, bien réfléchir avant d'appliquer les recettes, et mesurer les gains.

- Attention aux champs starttime et endtime (inspiré de l'extension dmc_highPerformance) : Une fonction pratique dans Typo3 est de pouvoir programmer l'apparition de contenu. Cela se traduit en fait pas l'ajout de tests sur les champs starttime et endtime lorsque la requête SQL est effectuée, c'est pratique mais il y a un revers à la médaille car cela réduit considérablement le nombre de requêtes qui peuvent être renvoyées par la cache de MySQL.
Pourquoi? Tout simplement car comme la comparaison se fait par rapport au timestamp auquel est executé le script, la requête change toutes les secondes et n'est donc pratiquement jamais renvoyée par le cache.
Il existe plusieurs solutions à ce problème :
- n'utiliser les champs starttime et endtime seulement si vos contenus doivent être programmés (= ne pas cocher systématiquement "Add starttime" et "Add endtime" dans le kickstarter.
- effectuer un arrondi sur le timestamp utilisé pour la comparaison. Au lieu d'utiliser systématiquement la fonction tslib_cObj::enableFields (qui ajoute donc entre autres ces fameux tests) construisez vous-même votre clause where en arrondissant le timestamp utilisé pour la comparaison :

Code

# exemple avec un arrondi de 10 minutes :
$now = time();
$now = $now - ($now % (10 * 60));
$where = ' AND matable.starttime >'.$now.' AND matable.endtime <'.$now;
# on appelle maintenant la classique fonction enableFields en ignorant les champs starttime et endtime
# notez que je n'utilise pas tslib_cObj.enableFields mais directement t3lib_pageSelect.enableFields  qui dispose de plus de paramètres
$where .= $GLOBALS['TSFE']->sys_page->enableFields('matable',0,array('starttime','endtime'));

documentation de t3lib_pageSelect.enableFields


- utilisez le cache! (ça fait pas de mal d'en remettre une couche)


5 - Optimisez vos templates

On peut obtenir des gains significatifs en optimisant dès le départ ses templates HTML :

- si vous utilisez jquery, scriptaculous, ou autre ne les stocker pas sur votre serveur (il vous dira merci), chargez les depuis Google, exemple :

Code

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>

pour ça, il suffit de l'ajouter en typoscript via page.headerData.

- chargez un minimum de CSS, il vaut mieux un seul fichier bien commenté qu'une miriade de petits fichiers

- chargez vos javascripts en fin de page.
Les javascripts ont le gros défaut d'être chargés de manière synchrone, donc si vos javascripts sont chargés dans votre head, votre page ne sera chargée qu'une fois les javascript chargés. Cela n'améliore pas le temps de chargement global de votre page mais cela améliore la sensation de vitesse pour vos utilisateurs (car ils peuvent voir le contenu plus tôt).
pour cela, un petit page.20 = COA dans votre typoscript et le tour est joué.
Personnellement, je charge jquery dans le head via Google, puis un tout petit javascript pour les initilisations indispensables et je charge tout le reste des javascripts en bas de page.
Là encore tout dépend de votre site.

Toutes ces optimisations de template sont mesurables grâce à l'outil YSlow de Yahoo présenté par Dmitry et Rakel pendant l'uni.


6 - utilisez mod_gzip ou mod_deflate

Il peut être intéressant d'activer la compression sur les fichiers js et css, je dis "peux être interessant" car selon le niveau de compression réglé dans apache par défaut, la charge sur le CPU du serveur peut être assez élevée (car la compression est effectuée à chaque fois), c'est donc encore une fois à tester selon votre site :

Code

<IfModule mod_deflate.c>
                <FilesMatch "\.(js|css)$">
                        SetOutputFilter DEFLATE
                </FilesMatch>    
</IfModule>

merci à Rakel de m'avoir signalé cet oubli


Attention à votre version de ameos_formidable
Si vous utilisez ameos_formidable 2.x, utilisez au moins la version 2.0.421, les versions précédentes sont affectées par un bug dans la gestion des sessions qui envoit des en-têtes HTTP erronés et désactive le cache côté-client pour TOUT VOTRE SITE (pas bon) : http://bugs.typo3.org/view.php?id=12283

[troll]Enfin... n'utilisez pas TemplaVoilà, c'est mal[/troll]

Voilà, si vous avez d'autres tuyaux, je les testerais et les ajouterais à cette liste.

Have fun!

Ce message a été modifié par duch - 12/04/2010, 20:50 .