Salut,
Je profite du message de Maurice pour faire un ch'tit topo sur la rapidité...
-> Le principe général du site public est d'être intégralement en cache, c'est-à-dire qu'un premier visiteur provoque le calcul d'une page, les suivants (dans un intervalle de temps que le webmestre a fixé lui-même) récupérant un fichier déjà tout calculé.
De fait, à part le premier visiteur, il n'y a plus aucun calcul de la part de SPIP, d'où une très grande vitesse. Le temps d'accès à la page étant celui, tout bêtement, d'une page HTML classique (chargement du texte et des images).
Ainsi, quelle que soit la complexité d'une page (multiples mots-clés, longue liste d'articles, etc.), la "vitesse de SPIP" n'est plus en jeu.
-> La difficulté principe viendra donc du "recalcul" de la page, c'est-à-dire la visite d'une page qui n'est pas encore en cache. C'est là qu'intervient du "gros" calcul de la part de SPIP, qui consiste en 5 actions:
(1) analyse du squelette,
(2) interrogations de la base de donnée pour récupérer les informations nécessaires,
(3) calculs sur ces données, notamment pour le traitement typographique, et insertion de ces résultats (du texte) dans le squelette,
(4) sauvegarde du fichier de cache,
(5) récupération de ce fichier cache et envoi au client.
La partie (1) d'analyse du squelette était relativement lourde dans les toutes premières versions (que la plupart d'entre vous n'ont pas connues); Antoine a entièrement reprogrammé cette partie, et désormais, quelle que soit la complexité du squelette, la phase d'analyse est très très rapide. C'est quasiment imperceptible. Notez que c'est dans cette phase que sont détectées les erreurs de construction des squelettes (tag boucle fermant manquant, etc.).
La partie (2) est, à priori, rapide, mais cela dépend énormément de la charge du serveur. De fait, s'il y a beaucoup d'éléments à récupérer depuis la base de données, ce temps peut être perceptible. Là, Antoine a commencé à optimiser, pour limiter le nombre de requêtes inutiles (récupérer des données qui ne seront pas utilisées dans la page). Il semble que récupérer des informations "lourdes" (textes longs notamment) prend du temps au niveau de la gestion de la mémoire du serveur (Antoine, tu m'arrêtes si je dis des bêtises). Si j'ai bien compris, cette optimisation est en cours, et encore incomplète.
La partie (3), entièrement en PHP (il n'y a plus d'interrogations de la base de données) est _très_ lourde. Notamment, sur les textes très longs, l'analyse typographique est très perceptible (jusqu'à plusieurs secondes). Un gros travail d'optimisation a déjà été réalisé sur cette partie, mais on n'échappe pas à l'utilisation, assez lourde, d'expression régulières, et cela est très long.
Les parties (4) et (5) sont quasi immédiates, totalement imperceptibles.
C'est donc sur les parties (2) et (3) que nous concentrons l'optimisation désormais. Notez qu'en quelques semaines, nous avons largement divisé les temps de calcul. Au début, certaines pages pouvaient prendre plus de 30 secondes de calcul, désormais il est rare de dépasser 5 secondes.
-> Le cas de Free...
Les machines de Free sont très lentes. Elles sont rapides pour "servir" du HTML sans calculs, d'où l'impression générale que Free est rapide. Mais dès qu'il y a des calculs PHP et des requêtes mySQL, les performances sont lamentables.
De plus, Free a fixé un délais maximum pour l'exécution des scripts de 5 secondes, ce qui est très peu (généralement, les hébergeurs laissent une durée de 30 secondes). Du coup, exécution lente des fonctions de SPIP, et sur certains textes très longs, on se retrouve à dépasser cette limite de 5 seconds. On obtient alors un message d'erreur, la page n'est pas calculée, et donc même pas sauvegardée en cache...
C'est dommage qu'au delà de 50 mots clefs il n'y ait pas à la fois la liste déroulante ET le moteur de recherche.
ou qu'il n'y ait pas un sélection double :
première liste> choix famille mots clefs deuxième liste> choix mots clefs dans la famille choisie troisième>moteur recherche
Le problème est double: à la fois un problème d'interface, et un problème de temps de chargement.
-> Interface
L'interface est une préoccupation centrale dans le développement de SPIP. Elle doit être _limpide_. L'utilisateur ne doit pas se demander pourquoi ni comment, il doit pouvoir se contenter de cliquer là où il faut cliquer pour obtenir le résultat désiré. Bien entendu, c'est toujours perfectible, mais c'est toujours l'optique dans lequelle le bidule est conçu.
De fait, il faut éviter les redondances d'interface, qui induisent un doute, parce que l'utilisateur se demandera toujours s'il doit utiliser l'un ou l'autre, et si ça fait la même chose. Donc menu déroulant unique (et non deux ou plus menus), donc on n'affiche pas à la fois le moteur et le menu déroulant.
Bien sûr, la présence des deux ferait gagner du temps aux utilisateurs aguerris, mais provoquerait une grande perplexité chez les autres... Pour te dire, il a fallu affronter des questions du genre "il y a une case pour le surtitre, mais je n'utilise pas de surtitre, est-ce que ça va poser un problème?"; questions qui n'ont rien d'illégitime.
-> Les temps de chargement
Le moteur de recherche remplace le menu déroulant quand il y a trop d'éléments. Ca n'est pas une question d'interface, c'est un problème de vitesse de téléchargement: le menu déroulant, quand il pèse 50ko, ralentit énormément le chargement de la page de l'article, alors même qu'il n'est pas utilisé à chaque fois. On avait notamment le problème avec le menu déroulant des auteurs dans uZine, très lourd à charger.
Amicalement,
ARNO*
--
Le Scarabée : http://www.scarabee.com
uZine 2 : http://www.minirezo.net
DH/DSS, 0x11930F0B, DEEB 602D B344 644B AF88 BF73 85F4 2297 1193 0F0B