2010-09-21 23 views
4

J'utilise xdebug avec PHP pour faire du profilage de performance. Mais quand je cours le même script plus d'une fois, je reçois souvent des moments très différents. Il est donc difficile de savoir combien de foi mettre dans les résultats.Rendre le profilage de performance PHP prévisible

De toute évidence, il se passe beaucoup de choses sur une machine qui peuvent affecter les performances de PHP. Mais y a-t-il quelque chose que je puisse faire pour réduire le nombre de variables, donc plusieurs tests sont plus cohérents?

Je suis en cours d'exécution PHP sous Apache, sous Mac OS X.

+0

@JW: juste curieux, y a-t-il quelque chose de caché dans ce test de performance? C'est ce qui est sur ma tête :) –

+0

Eh bien, c'est difficile à dire. Je n'ai pas de cache PHP comme APC. Et je ne fais que profiler le code PHP, donc je ne m'inquiète pas du fait que le navigateur cache quelque chose. Mais qui sait ce qui est mis en cache dans la mémoire par le système d'exploitation. –

Répondre

4
  1. Réduire le nombre de services non liés à la boîte, autant que possible.
  2. Réduit le nombre de processus Apache.
  3. Amorcez les différents caches en chargeant votre script plusieurs fois. Utilisez éventuellement un outil d'analyse comparative, tel que leou le siege d'Apache, pour vous assurer que tous les enfants Apache sont touchés.
  4. Affectez votre script à partir de la ligne de commande en utilisant curl ou wget afin qu'Apache ne serve qu'une ressource: le script lui-même.

Il peut y avoir un argument pour obtenir plus de nombres de «monde réel» en omettant certaines de ces étapes. J'attends d'autres réponses à cette question.

1
  1. Comme d'autres l'ont dit, réduire les services et les programmes en cours d'exécution à un minimum
  2. Exécutez votre test plusieurs fois de suite et moyenne pour tenir compte des valeurs aberrantes
  3. Faire la mise en cache sûr de toute sorte est désactivé (sauf si vous spécifiquement vouloir le tester avec un cache)
  4. Si les résultats varient encore largement, le problème est probablement dans votre code de profilage. Cela peut avoir des conditions de course ou dépend des connexions réseau. Vous obtiendrez plus de détails si vous fournissez le code
  5. Vous pourriez également rencontrer quelques goulets d'étranglement sur certaines des courses. Si vous profilez soigneusement différentes parties des scripts, vous pourrez peut-être l'attraper.
3

Il y a deux tâches différentes, mesurer la performance et trouver des problèmes. Pour mesurer le temps qu'il faut, vous devez vous attendre à une variabilité, car cela dépend de ce qui se passe dans la machine. C'est normal.

Pour trouver des problèmes, ce que vous devez savoir est le % du temps utilisé par diverses activités. Le pourcentage ne change pas trop en fonction d'autres choses, et la valeur exacte du pourcentage importe peu de toute façon.

Ce qui importe est que vous trouviez des activités responsables d'un pourcentage sain, que vous pouvez corriger, et que vous les corrigiez. Quand vous le faites, vous pouvez vous attendre à gagner du temps jusqu'à ce pourcentage, mais la conclusion est ce que vous devez faire. La mesure est secondaire.

Ajouté: Vous pourriez demander "Vous n'avez pas à mesurer pour trouver?" Considérons un exemple. Supposons que vous exécutiez votre programme avec le débogage activé, et vous le suspendez au hasard, et vous le voyez dans le processus de fermeture d'un fichier journal. Continuez, puis arrêtez de nouveau et voyez la même chose.Eh bien, cette "mesure" approximative indique qu'elle passe 100% de son temps à le faire. Naturellement, le temps passé à le faire n'est pas vraiment à 100%, mais quoi qu'il en soit, c'est énorme, et vous l'avez trouvé. Alors peut-être que vous n'avez pas besoin d'ouvrir/fermer le fichier si souvent, ou quelque chose comme ça. Typiquement, plus d'échantillons sont nécessaires, mais pas trop.