Ces mesures font apparaître les temps hallucinants dus à la couche de présentation.
Pour rappel, aujourd'hui :
1. Le traitement applicatif PHP remplit des DataBeans, c'est-à-dire des objets qui n'ont que des méthodes getXxx() et setXxx().
2. Le relais est ensuite passé à la couche de présentation, qui sérialise les DataBeans en XML par la méthode «toXml()». Pour de sordides raisons de limitations de PHP, on normalise le résultat en UTF-8 propre, avant d'appliquer la XSLT qui a servi au maquettage XHTML. On renormalise ça en UTF-8 propre, puis on formate le XHTML en HTML 4.01 «optimisé». Cela fait 5 passes où l'on utilise XML.
Ce sont ces passes qui prennent du temps.
Les mesures ont été faites en une heure, sur des écrans de consultation en mode debug, avec le jeu de données «dataset-005» (ça, c'est pour les intimes).
On a testé l'affichage d'une liste de 3 forums, l'affichage d'une liste de 38 messages dans un forum, en tri par date puis en tri par enfilade, l'affichage d'un message, avec une liste sous-jacente en tri par date puis en tri par enfilade.
1. Liste de 3 forums
XML du DataBean sérialisé : 13 Ko
HTML : 14 Ko
Temps total : 612 ms
Couche applicative : 226 ms (37%)
Couche de présentation : 374 ms (61%)
2. Liste de 38 messages, tri par date
XML du DataBean sérialisé : 29 Ko
HTML : 70 Ko
Temps total : 1400 ms
Couche applicative : 341 ms (24%)
Couche de présentation : 1042 ms (74%)
3. Liste de 38 messages, tri par thread
XML du DataBean sérialisé : 29 Ko
HTML : 59 Ko (il y a moins de lignes de séparation dans la table qu'en tri par date)
Temps total : 1275 ms
Couche applicative : 335 ms (26%)
Couche de présentation : 925 ms (73%)
4. Un message, avec liste sous-jacente triée par date
XML du DataBean sérialisé : 18 Ko
HTML : 23 Ko
Temps total : 924 ms
Couche applicative : 307 ms (33%)
Couche de présentation : 605 ms (65%)
5. Un message, avec liste sous-jacente triée par enfilade
XML du DataBean sérialisé : 18 Ko
HTML : 23 Ko
Temps total : 943 ms
Couche applicative : 340 ms (36%)
Couche de présentation : 587 ms (62%)
6. Répartitions moyennes détaillées :
- Couche applicative : 31%
- Couche de présentation : 67%
- Sérialisation du DataBean en XML : 2%
- Transformation XSLT : 29%
- Formatage du HTML : 22%
- Temps total des deux renormalisations en UTF-8 : 14%
Les pistes d'optimisations sont les suivantes, :
1. Ne plus s'appuyer sur XML pour la couche de présentation.
C'est-à-dire construire directement le HTML en PHP en une passe, au lieu d'utiliser XML sur 5 passes. C'est fou comme c'est plus rapide le PHP, si, si. On devrait gagner entre 50% et 60%.
Néanmoins il faut garder la skin XSLT, est passer des UAT avec, car c'est la seule qu'on ait aujourd'hui qui soit corrélée à un maquettage hors serveur.
2. Faire la mise en page davantage en CSS plutôt qu'en HTML.
On gagnera évidemment d'autant plus de temps que le HTML sortant sera proche d'un bête dump du DataBean.
2.1. Passer à des entités numériques (é) plutôt que codes (é) quand on y gagne. Sur «é» (é), on gagne 2 octets.
Le fait de ne transférer que des octets sur 7 bits n'est pas négociable. Donc autant gagner sur la taille des entités.
3. Afficher plusieurs messages par page.
S'il faut une seconde en dev (2 sec. en prod) pour afficher un message, ça va faire cher de la discussion.
Il faut impérativement permettre de lire les messages par lots.
Quand seront faites ces optimisations :
4. Pas avant l'automne.
Les optimisations 1 et 2 ne sont même pas critiques pour les premiers utilisateurs. On a des temps de réponse de l'ordre de 1,5 sec. sur poste de développement, donc de 3 sec. en production. Je parie que ça passe.
Pour l'optimisation 3, là, c'est sûr, ça va se voir. Cela dit, arrivons d'abord au béta-test.
Aucun commentaire:
Enregistrer un commentaire