Subject: Re: Perf ID
Newsgroups: gmane.comp.web.spip.devel
Date: 2007-12-24 07:35:47 GMT (1 year, 27 weeks, 5 days, 8 hours and 41 minutes ago)
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