Comment évaluer l'efficacité du script PHP

pour évaluer la vitesse à laquelle votre script complet tourne sur le serveur, il y a beaucoup d'outils que vous pouvez utiliser. Assurez-vous d'abord que votre script (preg_match vs strpos par exemple) doit afficher les mêmes résultats afin de qualifier votre test.

vous pouvez utiliser:

• jmeter
• ApacheBench outil ( voir un exemple )
• dbench
• http_load
• curl-loader
• httperf
• siège
• vegeta
• le code que vous utilisez est bon aussi, mais avec une plus grande boucle (comme 1.000.000)

vous voudrez regarder Xdebug et plus spécifiquement, xdebug's profiling capabilities .

fondamentalement, vous activez le profileur, et chaque fois que vous chargez une page web il crée un fichier cachegrind qui peut être lu avec WinCacheGrind ou KCacheGrind .

Xdebug peut être un peu difficile à configurer donc voici la section pertinente de mon php.ini pour référence:

[XDebug]
zend_extension = h:\xampp\php\ext\php_xdebug-2.1.1-5.3-vc6.dll
xdebug.remote_enable=true
xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir=h:\xampp\cachegrind
xdebug.profiler_output_name=callgrind.%t_%R.out

Et voici une capture d'écran d'un fichier .out dans WinCacheGrind :

qui devrait fournir de nombreux détails sur l'efficacité de votre script PHP. Vous souhaitez cibler les choses qui prennent le plus de temps. Par exemple, vous pourriez optimiser une fonction pour prendre la moitié du temps, mais vos efforts seraient mieux servi optimiser une fonction qui est appelée des douzaines sinon des centaines de fois pendant une charge de page.

si vous êtes curieux, ce N'est qu'une ancienne version d'un CMS que j'ai écrit pour mon propre usage.

Try https://github.com/fotuzlab/appgati

il permet de définir des étapes dans le code et rend compte du temps, de l'utilisation de la mémoire, de la charge du serveur, etc. entre deux étapes.

quelque chose comme:

    $appgati->Step('1');

    // Do some code ...

    $appgati->Step('2');

    $report = $appgati->Report('1', '2');
    print_r($report);

Exemple de tableau de sortie:

Array
(
    [Clock time in seconds] => 1.9502429962158
    [Time taken in User Mode in seconds] => 0.632039
    [Time taken in System Mode in seconds] => 0.024001
    [Total time taken in Kernel in seconds] => 0.65604
    [Memory limit in MB] => 128
    [Memory usage in MB] => 18.237907409668
    [Peak memory usage in MB] => 19.579357147217
    [Average server load in last minute] => 0.47
    [Maximum resident shared size in KB] => 44900
    [Integral shared memory size] => 0
    [Integral unshared data size] => 0
    [Integral unshared stack size] => 
    [Number of page reclaims] => 12102
    [Number of page faults] => 6
    [Number of block input operations] => 192
    [Number of block output operations] => 
    [Number of messages sent] => 0
    [Number of messages received] => 0
    [Number of signals received] => 0
    [Number of voluntary context switches] => 606
    [Number of involuntary context switches] => 99
)

je regarderais dans xhprof . Peu importe qu'il soit lancé sur le cli ou via un autre sapi (comme fpm ou fcgi ou même le module Apache).

la meilleure partie de xhprof est qu'il est même assez apte à être utilisé en production. Quelque chose qui ne fonctionne pas aussi bien avec xdebug (dernière fois que j'ai vérifié). xdebug a un impact sur la performance et xhprof (Je ne dirais pas qu'il n'y en a pas) gère beaucoup mieux.

nous utilisons fréquemment xhprof pour recueillir des échantillons avec le trafic réel et d'analyser le code à partir de là.

ce n'est pas vraiment un point de référence en termes qu'il vous obtient un temps et tout cela, mais il fait cela aussi. Cela rend juste très facile d'analyser le trafic de production et puis descendre au niveau de la fonction php dans le calligraphe recueilli.

une fois l'extension compilée et chargée, vous commencez le profilage dans le code avec:

xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

pour arrêter:

$xhprof_data = xhprof_disable();

puis enregistrez les données dans un fichier, ou une base de données - peu importe ce qui fait flotter votre bateau et n'interrompt pas l'exécution habituelle. Nous poussons de façon asynchrone ceci à S3 pour centraliser les données (pour être en mesure de voir toutes les sorties de tous nos serveurs).

le code sur github contient un dossier xhprof_html que vous déchargez sur le serveur et avec une configuration minimale, vous pouvez visualiser les données collectées et commencer à forer vers le bas.

HTH!

mettez-le dans une boucle for pour faire chaque chose 1.000.000 de fois pour obtenir un nombre plus réaliste. Et ne démarrez la minuterie que juste avant le code que vous voulez réellement comparer, puis enregistrez le temps de fin juste après (i.e. ne démarrez pas la minuterie avant le session_start() .

assurez-vous Également que le code est identique pour chaque fonction que vous souhaitez pour référence, à l'exception de la fonction de synchronisation.

comment le script est exécuté (cronjob, php en ligne de commande, Apache, etc ... ) ne devrait pas faire de différence puisque vous chronométrez seulement la différence relative entre la vitesse des différentes fonctions. Ce ratio devrait donc rester le même.

si l'ordinateur sur lequel vous exécutez le benchmark a beaucoup d'autres choses en cours, cela pourrait affecter les résultats du benchmark s'il se trouve qu'il y a un pic dans L'utilisation CPU ou mémoire d'une autre application pendant que votre benchmark est en cours d'exécution. Mais aussi longtemps que vous avez beaucoup de ressources disponibles sur l'ordinateur alors je ne pense pas que ce sera un problème.

un bon début est d'utiliser xdebugs profiler http://xdebug.org/docs/profiler

peut-être pas la chose la plus facile à mettre en place et à utiliser, mais une fois que vous l'obtenez va le volume de données et la facilité de visualisation est irremplaçable.

Eric,

vous Vous posez la mauvaise question. Si votre script est exécuté dans ~15 mSec alors son temps est largement hors de propos. Si vous exécutez sur un service partagé, alors l'activation de L'image PHP prendra ~100 mSec, en lisant dans les fichiers de script ~30-50 mSec si entièrement caché sur le serveur, peut-être 1 seconde ou plus si vous êtes chargé à partir d'une ferme NAS d'arrière-plan. Les retards de réseau sur le chargement des meubles de page peuvent ajouter beaucoup de secondes.

le principal question voici la perception du temps de chargement par les utilisateurs: combien de temps doit-il attendre entre le clic sur le lien et l'obtention d'une page entièrement rendue. Regardez Google Page Speed que vous pouvez utiliser comme extension Ff ou chrome, et la documentation Pagespeed qui discute en profondeur comment obtenir de bonnes performances de page. Suivez ces directives et essayez d'obtenir des scores supérieurs à 90/100. (La page d'accueil de google a une note de 99/100, tout comme mon blog). C'est le meilleur moyen obtenir une bonne performance perçue par l'utilisateur.

Il est également bon de garder vos yeux sur votre code PHP et de les recouper avec ce lien , afin de s'assurer que votre code lui-même n'est pas potentiellement perturber les performances de l'application.