routing.md 4.2 KB
Optimisation de la résolution d'URLs (routing)
Problématique initiale
Typo3 n'a pas été pensé pour héberger des milliers de sites comme c'est le cas ici, Ce qui provoque un certain nombre de lenteurs, au niveau de l'affichage de certains écrans du backend par exemple. Une conséquence est que la résolution des urls par le système de routing est longue et consomme trop de puissance de calcul, causant à la fois une dégradation des performances et un risque de déni de service.
Le problème se pose à la fois dans le cas d'une page existante (200) et d'une page inexistante (404), car les erreurs 404 impliquent la même charge de travail pour le serveur que les pages existantes.
Deux étapes sont principalement concernées:
La résolution du domaine
Pour associer le domaine utilisé à un site, le routeur Typo3 parse les fichiers de configuration config.yaml stockés dans /var/www/typo3/config/sites
Il existe un fichier par site, soit près de 6000 dans notre cas en 2021.
Au premier affichage, le temps d'accès disque et de parsing est donc extrêmement long.
Lors des accès suivants, ces configurations sont en cache, ce qui réduit l'impact.
Cependant, le router instancie tous les sites avant de faire finalement correspondre le domaine utilisé dans la requête à l'uid de la page racine d'un site.
La résolution du chemin
Une fois la correspondance entre le domaine et un site effectuée, une deuxième étape consiste à résoudre le chemin (path, ou slug) et à le faire correspondre à une page.
Encore une fois, typo3 n'est pas conçu pour héberger autant de site. Pour effectuer cette résolution, Typo3 récupère en base toutes les pages dont le slug correspond à la requête. Ensuite, le routeur vérifie pour chacune de ces pages si elle fait partie du site déterminé à l'étape précédente.
Ce qui implique, lorsque la requête concerne un slug commun comme la page d'accueil '/', que jusqu'à 6000 requêtes peuvent être effectuées en base pour la résolution d'une seule page!
Mesures d'optimisation
Pour parer à ces problèmes, l'extension ot_optimizer implémente des XClass qui vont se substituer à certaines classes Typo3 responsable du routing.
Le rôle de ces classes sera donc de faire correspondre un domaine à un site via les enregistrements de la table 'ot_websites', puis un slug à l'uid d'une page grâce au champs 'slug' de la table 'pages'.
IMPORTANT: ces mesures ne sont appliquées qu'aux requêtes Frontend.
Garder les routes à jour
Un hook est nécessaire dans le logiciel pour garder à jour le champs 'subdomain' de la table 'ot_websites'.
Ce hook est déclenché par la requête http: <typo3_host>/typo3/otadmin/site/update?organization-id=<organization_id>
La redirection peut-être ajoutée en ligne de commande (voir ot_admin)
Faut-il prévoir un fallback vers le fonctionnement par défaut?
Aucun fallback vers le router natif de Typo3 n'est prévu, car un fonctionnement de ce genre annulerait les bénéfices de l'index dans le cas des erreurs 404.
Cas particuliers
Gérer les redirections
Certains domaines font l'objet de redirections vers un autre nom de domaine. Il faut s'assurer que cette redirection puisse avoir lieu.
Les pages à accès restreint
Les pages à accès restreint doivent apparaître dans la table de routage, Typo3 se chargera ensuite de déterminer si l'utilisateur a le droit d'y accéder ou non.
Les pages de type raccourci
Les pages de type raccourci doivent apparaître dans la table de routage comme des pages normales, Typo3 se chargera ensuite de la redirection. En effet, si on voulait gérer cette redirection directement au niveau de la table de routage, il faudrait tenir compte du cas supplémentaire où la cible du raccourci est changée.
Les urls en mode développement
En mode développement (sur preprod ou en local), les urls ne sont pas construites de la même manière:
| Prod | Dev |
|---|---|
<subdomain>.opentalent.fr |
`host.opentalent.fr/ |