Le 24 déc. 07 à 00:14, nicolasriq <at> free.fr a écrit :

>
>> Le 23 déc. 07, à 01:06, Matthieu Marcillaud a écrit :
>> Ben vient de copier contrib sur scriibe pour faire des tests de  
>> charge.
>> On peut donc le croiser ici : http://spipcontrib.scriibe.net/
>
> bonne nouvelle on va enfin pouvoir travailler sur des éléments  
> factuels
...
> - il me semble qu'il y a quelque chose de pas très net du coté du
> comportement du (des ?) cache(s) sur les serveurs mutualisés (avec des
> filers etc ...) ... car les lenteurs de calculs à juste titre  
> constatés
> devraient il me semblent être très atténués par le cache.
...
> - bref le temps brut de calcul me parait peu pertinent s'il n'est
> ramené à une fréquence de recalcul
> - il s'agit seulement de l'entrée dans le site, la perception de
> lenteur est évoquée dans tout le site .. ce ne sont donc pas ces
> requêtes qui sont, et de loin, seules en cause.
....
> proposer à terme une page coté admin (dans le
> core ou comme plugin) qui proposerait une analyse des temps de calculs
> en situation réelle
....
> Autant les stats de visites sont utiles je pense pour suivre la vie du
> site (par les variations qu'elles indiquent plus que par leurs valeurs
> absolues toujours discutables), autant les referers le sont peut etre
> beaucoup moins (inutilisés sur Contrib à ma connaissance), au moins
> dans le temps (sur quelques jours cela devrait suffire ?). J'ai
> souvenir d'un temps ou l'on pouvait activer séparément les deux, je
> propose que cela soit refait

D'accord avec ces remarques Nicolas.
Je vais dans ton sens en disant nettement que la perception de lenteur  
pour l'usager d'un site n'est pas celle qu'en a son hébergeur. Pour ce  
dernier, ce qui compte c'est qu'un site ne monopolise pas les  
ressources communes avec les autres sites, et donc en premier lieu le  
serveur SQL. Mais d'une part ce n'est pas la seule ressource  
mutualisée, il y a aussi le système de fichiers et je ne dirai  
visiblement jamais assez que les hébergeurs ne font pas leur boulot en  
ne proposant pas la mutualisation de SPIP lui-même car ça optimiserait  
cette ressource.

D'autre part, l'hébergeur est moins concerné par la lenteur de PHP car  
l'impact sur les autres sites est moins fort que le serveur SQL, mais  
pour l'utilisateur la distinction n'est pas visible. Il faudrait déjà  
déterminer le ratio de temps de calcul entre les deux: si l'essentiel  
du temps de calcul est du côté de PHP, s'escrimer à optimiser les  
requêtes SQL ne servira pas à grand chose pour les visiteurs, juste à  
se faire bien voir des hébergeurs (ce qui n'est pas négligeable cela  
dit).

Enfin, depuis la 1.9 SPIP utilise beaucoup plus JavaScript, ce qui  
fait que le temps d'affichage dépend beaucoup plus du client  
qu'auparavant. A la limite, SPIP pourrait juste extraire de la BD ce  
qui est nécessaire à la page demandée, puis balancer une page  
essentiellement JavaScript contenant ces données et une fonction de  
mise en page équivalente à ce qui est fait en PHP aujourd'hui:  
l'hébergeur serait super content, le visiteur infiniment moins.

Donc, oui, il manque un outil permettant d'identifier où les perfs  
sont problématiques, mais c'est un très gros chantier.

Committo,Ergo:Sum