Depuis quelques jours, je constate que mon couple apache2+php4 se met parfois à bouffer 90% du CPU pendant quelques secondes (commande top sous Linux) !
Sur le site que j'héberge, j'ai tout un paquet de pages, avec des include dans tous les sens.
 
Y a-t-il un moyen simple (classe ou script existants) pour mesurer les performances du serveur  et déterminer quelle page ou quelle "sous-page" (include) prend du temps à l'exécution ?

question con : en quoi c'est mal qu'une application prenne tout le CPU lorsqu'elle en a besoin et qu'elle en a la possibilité ?

 
En rien.
Le problème c'est que dans mon cas, elle ne devrait pas en avoir besoin, ni la possibilité.
 
Le but du site c'est que plusieurs personnes le visitent en même temps, et pas une seule à la fois.
Dans ma question, il est bien sûr implicite que l'application en question ne devrait pas bouffer 99% du CPU, et encore moins pendant plusieurs secondes.

Question con : qu'est ce que t'en sais que c'est une seule demande de page qui nécessite plusieurs secondes CPU et paspas plusieurs demandes en simultanées qui donne cette impression?
 
En tout cas, si tu veux savoir quel script est trop gourmand, il te reste plus qu'a trouver l'heure du top et à regarder les fichiers de log d'apache pour voir quelles demandes de pages correspondent à cette heure là.

 
Salut tu as une classe sous PEAR qui permet du faire du benchmark de scripts  
 
http://pear.php.net/package/Benchmark
 
Fais une petite recherche il y apleins de tutoriels sur le net
 
 

sky_striker> Tu as raison de te citer toi-même.

Merci pour la classe sky_striker, j'aurai au moins eu une vraie réponse.
Entre temps j'ai bricolé moi-même en mettant des timer un peu partout sur les pages que je soupçonnais, pour voir à quels endoits il y avait des latences.
 
Il s'avère que les fonctions suivantes sont horriblement lentes:
is_array (environ 40ms)
array_merge (environ 100ms)
 
je ne comprends pas comment des fonctions intégrées peuvent être aussi lentes ...
Du coup j'ai remplacé les is_array par isset qui me suffit largement; et et array_merge par une boucle toute simple qui recopie les valeurs d'un tableau dans un autre ...  
 
Ex d'utilisation:
if(!is_array($toto)) { $toto = array(); }
devient
if(!isset($toto)) { $toto = array(); }
[...]
$toto = array_merge($toto,$titi);
devient
foreach($titi as $k=>$v) { $toto[$k] = $v; }
 
Avec plus de 200 clients simultanément sur le site, ça fait une sacrée différence, le temps de génération d'une même page est passée de 250 ms à 40 ms environ !

Tu es sûr de tes conclusions ? sans offense
après des essais locaux, genre  

je tire les conclusions suivantes
pas de comparaisons entre is_array et isset vu que le temps d'exe d'un isset n'est pas notable
et que je compare pas des carrotes avec des choux-fleur
is_array temps quasi constant sur taille de tableau de 700 000 entrées contenant en valeur l'index
moyenne par 20 machine a 0.00008 (prod., mutualisée, linux, bi-optéron)
moyenne par 20 machine b 0.00019 (dev., dédiée, linux, 700Mhz)
quant à array_merge vs itération/affectation
avec 2 tableaux plus petit 100 000 entrées (mémoire oblige)
je constate une variation entre - de 1% à 3% en défaveur de array_merge()
pas de moyenne cette fois ...
mais si tu tapes des clés mixtes string + int ça va devenir moins drôle ...
 
donc tout ça pour dire mon étonnement ...

 
Ouais enfin, on n'a pas tout à fait les mêmes moyens ... Mon serveur est un pauv P4 2800 Mhz, mais les tableaux que ja manipule, ce sont des tableaux associatifs de 50 éléments à tout péter ... D'où mon étonnement sur la lenteur. J'ai fait exactement le même test que toi avec timerstart et timerstop.
 
Je suis d'accord que is_array n'est pas comme isset, mais dans mon cas, la variable que je teste, quand elle est définie, est forcément un tableau, l'utilisation de is_array était pour le principe, mais quand je vois le résultat, je me contente d'un isset ...
 
Pour le array_merge, j'ai donc 2 tableaux associatifs (dont toutes les clés sont des string), qui ont environ 50 valeurs chacuns, et je veux les fusionner en un seul tableau (qui aura 100 valeurs maximum à priori). Vu la quantité ridicule de données, je ne comprends pas que ça soit si lent.
 

pour les moyens : mouais, orf, tu sais ...
et pour la taille, j'ai pris des extrêmes, histoire de voir le max ...

je disais ça pour l'anecdote ... mais si tu es sûr que ton tableau t'arrive en bonne forme, ya pas de raisons ...

bon trève de chitchat ...
je suis bien d'accord que c'est là qu'est l'interrogation, je ne comprends pas bien non plus, surtout si l'énum./affectation est à ce point plus rapide ... as-tu essayé de faire le test hors contexte de ton appli ?
histoire de voir si elle est totalement hors du coup ?
ou de tester la vitesse à interval régulier, genre logguer le résultats de tes timers, pour voir si y'a pas une question de montée en charge ? hmm, tu es en dédié ? tu as dû déjà le vérifier ...

 
Ce qui est curieux c'est que j'ai déjà utiliser array_merge sur des tableaux beaucoup plus grand et je n'ai pas constaté de lenteur ... Peu être que le poid de la donnée elle même est en cause. Concatener deux tableau de 2 élément de 10000 caractéres ça peu faire ramer.
 
C'est une idée que j'ai ... Je ne sais pas ce que contienne tes tableaux ...
 
Ce que tu peux faire pour en être certains c'est initialiser manuellement t tableaux et regarder ce que ça donne. C'est peu être ta façon de mésurer qui déconne ...
 
Voila