Au fil du temps, tout programmeur PHP est confronté au problème des mauvaises performances de son application. Il se peut qu'une page particulière se charge lentement ou que la réponse de l'API prenne trop de temps. Et parfois, il est assez difficile de comprendre quelle est la raison des freins ? Parfois, des situations plus complexes se produisent : sur le serveur de production, l'API est très lente, mais sur le banc où s'effectue le développement, tout va bien. Et va comprendre ce qui ne va pas. Le débogage sur un serveur de production est un degré extrême de désespoir, auquel, bien entendu, il vaut mieux ne pas conduire.

C'est pour de telles situations que des outils spéciaux appelés profileurs d'applications ont été inventés. Dans le monde PHP, ce rôle est joué par xDebug, ainsi que par xhprof. xhprof est un outil plus léger, plus simple et plus flexible, son utilisation est donc préférable. Fait intéressant, xhprof a été développé par Facebook en 2009, mais il n'y a toujours pas de support officiel pour php7 de leur part et il n'y en aura plus depuis que Facebook est passé à HHVM. Cependant, grâce à la vaste communauté de développeurs PHP, un fork est apparu prenant en charge PHP7, dont l'installation ne pose aucune difficulté.

Installation

Vous devez d’abord installer xhprof :

Clone Git https://github.com/longxinH/xhprof xhprof cd xhprof/extension phpize ./configure --with-php-config=/usr/bin/php-config sudo make && sudo make install mkdir /var/tmp/ xhprof

Extension=xhprof.so xhprof.output_dir="/var/tmp/xhprof"

Le dossier /var/tmp/xhprof doit avoir un accès en écriture, car les résultats du profilage y seront enregistrés.

Vous pouvez recharger PHP-FPM et vérifier si l'extension est installée. C'est banal, cela peut être fait en utilisant la sortie de la fonction phpinfo() ;

xhprof est installé, vous pouvez l'utiliser. Le package xhprof comprend une interface très conviviale pour analyser les rapports de profilage. xhprof vous permet de créer des rapports, à la fois sous forme textuelle et graphique. Le dossier d'installation de xhprof contient xhprof_html et xhprof_lib, dont nous aurons besoin. Dossier xhprof_html - donne accès à l'interface graphique. xhprof_lib - bibliothèque pour afficher et analyser le code. Il est conseillé de déplacer l'intégralité du dossier xhprof vers /var/www/xhprof et de configurer un hôte virtuel pour celui-ci, par exemple xhprof.loc. Exemple pour nginx :

Serveur ( écoute 80 ; nom_serveur xhprof.loc ; jeu de caractères utf-8 ; racine /var/www/xhprof/xhprof_html ; index index.php; emplacement / ( try_files $uri $uri/ /index.php?q=$uri&$args ; ) emplacement ~ \.php ( fastcgi_pass 127.0.0.1:9000; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; ) )

Vous devez également penser à mettre à jour le fichier hosts. Désormais, lorsque nous entrons l'URL xhprof.loc dans le navigateur, nous serons redirigés vers l'interface Web du profileur, où les fichiers générés par celui-ci seront disponibles.

Vous pouvez maintenant procéder directement au profilage du code.

Pour activer le profileur, utilisez la fonction xhprof_enable(), qui accepte les indicateurs suivants en entrée :

• XHPROF_FLAGS_CPU - pour enregistrer les statistiques du processeur ;
• XHPROF_FLAGS_MEMORY - pour la mémoire ;
• XHPROF_FLAGS_NO_BUILTINS - pour ignorer les fonctions intégrées.

Pour désactiver le profileur, utilisez la fonction xhprof_disable(). Pour plus de commodité, nous écrirons deux scripts header.php et footer.php qui remplissent ces fonctions. header.php est inclus au début du script profilé et footer.php à la fin. footer.php est également responsable du stockage des données de profilage.

header.php : if (extension_loaded("xhprof")) ( include_once "/var/www/xhprof/xhprof_lib/utils/xhprof_lib.php"; include_once "/var/www/xhprof/xhprof_lib/utils/xhprof_runs.php"; xhprof_enable(XHPROF_FLAGS_CPU); ) footer.php : if (extension_loaded("xhprof")) ( $profilerNamespace = "NOM DU PROFILED_SCRIPT ICI"; $xhprofData = xhprof_disable(); $xhprofRuns = new XHProfRuns_Default(); $runId = $xhpro fRuns->save_run ($xhprofData, $profilerNamespace); )
Usage

Après avoir connecté header.php et footer.php au script profilé, vous pouvez commencer : lors de l'exécution du script profilé, un fichier sera généré qui sera enregistré dans le répertoire /var/tmp/xhprof, contenant des informations sur le fonctionnement du scénario. Lorsque vous ouvrirez l'interface web xhprof.loc, ce fichier généré sera disponible :

Lorsque vous ouvrez un fichier de profilage, des informations détaillées sur le fonctionnement de l'application apparaissent, l'intégralité de la pile d'appels :

Que signifient les colonnes :

• Appels- nombre et pourcentage d'appels de fonctions ;
• Incl. L'heure du mur- temps d'exécution d'une fonction avec des fonctions imbriquées ;
• Hors. L'heure du mur- temps d'exécution d'une fonction sans fonctions imbriquées ;
• Incl. CPU- Temps CPU avec fonctions imbriquées ;
• Hors. CPU- Temps CPU sans fonctions imbriquées ;
• Incl. Utilisation de la mémoire- consommation mémoire avec fonctions imbriquées ;
• Hors. Utilisation de la mémoire- consommation de mémoire sans fonctions imbriquées ;
• Incl. Utilisation de PeakMem- consommation mémoire maximale avec fonctions imbriquées ;
• Hors. Utilisation de PeakMem- consommation de mémoire maximale sans fonctions imbriquées.

Si vous suivez le lien, une belle arborescence d'appels s'affichera avec une indication visuelle du code le plus lent. Si cela ne se produit pas, vous devrez probablement installer la bibliothèque graphviz :

Apt-get install graphviz

Un exemple de graphe construit :

Dans mon cas, le goulot d'étranglement est l'interaction avec la base de données.

Utiliser xhprof sur un serveur de production

Initialement, xhprof a été développé spécifiquement dans le but de profiler du code en combat, sur des serveurs de production. Il n'existe tout simplement aucun autre outil gratuit et efficace pour profiler le code PHP7 en combat, xhprof n'a donc pas de concurrents. Plus précisément, j'ai de l'expérience dans l'utilisation de xhprof sur un serveur de production qui traite un million de requêtes par jour. Il utilise php7 et aucun problème n’a été trouvé jusqu’à présent. Cependant, xhprof n'est pas exécuté pour chaque requête : cela générerait trop de fichiers de profilage. Pour moi, le profileur ne démarre que si la requête a l'en-tête « XHPROF_ENABLE » et qu'elle est définie sur true. Vous pouvez également utiliser une autre stratégie, par exemple exécuter le profileur de manière aléatoire avec une probabilité de, disons, 1/1000. Ensuite, il y aura également une image assez claire.

Conclusion

Même si xhprof n'est pas officiellement pris en charge pour php7, il reste un outil indispensable pour un développeur php.

Dernière mise à jour : 01/12/2019

Parution : 01/09/2016

Grâce à PhpStorm, vous pouvez analyser les performances de votre code PHP en le profilant. Le profilage vous permettra de collecter des statistiques d'exécution du programme : les noms des fonctions exécutées, combien de fois chaque fonction a été exécutée, le temps d'exécution de chaque fonction, quelles autres fonctions ont été appelées au sein de chaque fonction, etc.

Ces informations peuvent vous donner des indications sur les domaines dans lesquels votre code peut être amélioré.

Voyons voir comment ça fonctionne.

1. Conditions préalables

PhpStorm IDE peut utiliser les informations de profilage collectées à l'aide de l'outil Xdebug. Cette extension doit être installée et configurée sur votre système. Pour plus d'informations, consultez le Guide d'installation de Xdebug.

Si vous êtes un utilisateur de la merveilleuse plate-forme de serveur portable et de l'environnement logiciel Open Server, vous n'avez rien à faire - l'extension Xdebug est déjà installée et connectée.

Attention

Xdebug n'est pas compatible avec IonCube. IonCube est un outil (utilitaires) de protection des logiciels écrits dans le langage de programmation PHP. Désactivez complètement l'extension IonCube ou lors de l'utilisation de Xdebug. Un autre problème possible pourrait être que Xdebug est configuré par défaut sur le port 9000, qui est le même port utilisé par Open Server. Pour résoudre ce problème, dans l'un des cas, vous devez modifier le numéro de port.

Toutes les actions décrites ici ont été reproduites avec les résultats attendus corrects dans l'environnement technologique suivant :

2. Activation du profileur Xdebug

Le profilage ajoute une certaine surcharge à l'exécution de l'application et génère une énorme quantité d'informations sur le disque. Par conséquent, il est préférable d'activer le profileur Xdebug uniquement lorsque cela est nécessaire et de le désactiver dans des circonstances normales.

Xdebug est configuré via des directives dans le fichier php.ini actif. Chaque fois que vous activez le profileur, vous devez configurer la directive suivante :

xdebug.profiler_output_dir = /chemin/vers/store/snapshots

La valeur de la directive doit spécifier le chemin qui sera utilisé pour enregistrer les fichiers de profilage.

2.1. À l'échelle mondiale

Pour activer le profileur Xdebug globalement, vous devez utiliser la directive suivante :

xdebug.profiler_enable = 1

De cette façon, le profilage sera effectué à chaque fois qu’un script sera exécuté. Il est pratique d'utiliser cette option pour activer le profileur uniquement dans de rares cas.

2.2. Utilisation d'options d'interprétation supplémentaires

Vous pouvez activer le profileur à l'aide de paramètres d'interpréteur supplémentaires dans la fenêtre Configurations d'exécution/débogage. Pour l'ouvrir, utilisez les éléments suivants dans le menu principal de l'IDE :

L'option (marquée d'un contour rouge dans la capture d'écran ci-dessus) Section Options de l'interprète (options de l'interprète) Ligne de commande (ligne de commande) doit contenir la ligne suivante :

D xdebug.profiler_enable = 1

Cette option vous permettra d'utiliser le profileur pour une configuration spécifique, et non à l'échelle globale.

2.3. Utilisation de paramètres GET/POST spéciaux ou d'un fichier cookie

Pour un profilage plus contrôlé, la directive suivante doit être utilisée :

xdebug.profiler_enable_trigger = 1

Si la valeur de la directive est définie sur 1, alors lors de l'exécution d'un script avec un paramètre GET/POST ou un cookie nommé XDEBUG_PROFILE, le profilage sera effectué quel que soit le paramètre xdebug.profiler_enable.

Cette option pour activer le profileur est la plus populaire.

3. Collecte des journaux de profilage

Pour pouvoir analyser les journaux de profilage, ils doivent d’abord être collectés.

3.1. Collection de journaux de profilage pour les applications Web

Pour profiler des applications Web, utilisez le profileur Xdebug globalement ou démarrez-le et arrêtez-le à la demande. Après avoir activé le profileur, ouvrez l'application dans le navigateur pour commencer à collecter des données - journaux de profilage.

Lors de l'analyse des problèmes de performances, l'utilisation de bookmarklets ou d'extensions de navigateur pour le débogage est une très bonne approche car elle vous permet de naviguer dans l'application et de lancer le profileur uniquement lorsqu'un problème de performances est détecté. Cela vous permet de collecter des journaux de profilage ciblés.

3.2. Collection de journaux de profilage pour les applications CLI et les tests unitaires

Pour profiler les applications CLI et les tests unitaires, utilisez le profileur Xdebug globalement ou créez une configuration d'exécution distincte pour activer le profileur à l'aide de la fenêtre Configurations d'exécution/débogage. Exécutez ensuite l’application CLI ou les tests unitaires pour collecter les données de profilage.

Lors de l'analyse des problèmes de performances dans les tests unitaires, une bonne approche consiste à créer une configuration distincte pour exécuter uniquement les tests unitaires suspectés de rencontrer des problèmes de performances. Cela vous permet de collecter des journaux de profilage ciblés.

4. Analyse de la description du journal de profilage

Examinons de plus près le journal de profilage.

4.1. Ouverture du journal de profilage

Pour ouvrir le journal de profilage, utilisez les éléments suivants dans le menu principal de l'EDI : .

Si vous êtes un utilisateur de la merveilleuse plate-forme de serveur portable Open Server, vous pouvez également utiliser l'outil multiplateforme Webgrind pour afficher le journal de profilage. Il peut être trouvé via les éléments suivants du menu principal d'Open Server [Avancé → Profileur PHP].

Les journaux de profilage sont enregistrés dans un dossier conformément à la directive xdebug.profiler_output_dir configurée. Le nom du fichier généré commence toujours par cachegrind.out. et se termine soit par l'ID du processus PHP ou du serveur Web, soit par le hachage crc32 du répertoire dans lequel se trouve le script profilé.

4.2. Onglet Statistiques d'exécution

Dans l'onglet Statistiques d'exécution, vous pouvez examiner des informations récapitulatives sur les métriques d'exécution de chaque fonction appelée. Vous pouvez voir tous les fichiers, les appels de fonction, combien de fois ils ont été appelés et le temps d'exécution (absolu et relatif) de chaque fonction.

La grille supérieure affiche diverses mesures :

• Temps personnel - le temps qu'une fonction passe à exécuter son code (sans prendre en compte les appels à d'autres fonctions).

La grille inférieure affiche deux onglets : Appelés - les fonctions que le script appelle ici et Appelants - à partir desquels le script a été appelé. Vous pouvez voir diverses mesures ici :

• Temps - temps d'exécution total.
• Appels - nombre d'appels.

Les fonctions avec un temps d'exécution long ou un grand nombre d'appels nécessitent certainement des tests.

4.3. Onglet Arborescence des appels

L'onglet Call Tree affiche les chemins d'exécution de votre code. Ici, vous pouvez voir des informations plus détaillées sur le temps d'exécution de chaque fonction, etc.

La grille supérieure affiche les arborescences d'appels (quelles fonctions sont appelées dans d'autres fonctions) et d'autres métriques :

• Appelable (fichier appelé) - le fichier qui a été exécuté.
• Temps - temps d'exécution total.
• Appels - nombre d'appels.

La grille inférieure affiche deux onglets : Appelés - fonctions appelées ici et Appelants - à partir desquels la fonction est appelée. Vous pouvez voir diverses mesures ici :

• Callable (fonction appelée) - une fonction qui a été exécutée.
• Temps - temps d'exécution total.
• Appels - nombre d'appels.

Questions de contrôle

1. Pourquoi les applications PHP sont-elles profilées ?
2. De combien de manières principales existe-t-il pour activer le profileur Xdebug ?
3. Quelle est la meilleure façon de procéder lors du profilage des applications CLI et des tests unitaires ?
4. Quels outils peuvent être utilisés pour analyser les journaux de profilage ?
5. Lors de l’analyse d’un journal de profilage, à quelles mesures devez-vous prêter attention en premier ?

FirePHP est une extension pour Firebug qui, en conjonction avec sa petite classe php, vous permet de diffuser des données depuis php, par exemple toutes sortes de var_dump et d'autres informations de débogage, vers la console Firebug. Le principal avantage de cette extension est que toutes les informations de débogage sont diffusées via des en-têtes et n'encombrent pas les pages et ne brisent en aucun cas la logique de l'application. Site officiel : http://firephp.org/.

Idée principale.

L'algorithme de profilage général est le suivant :

1. Au début de la page, nous activons le profilage en utilisant xhprof_enable()
2. À la fin de la page, désactivez le profilage à l'aide de xhprof_disable() et enregistrez les données collectées à l'aide de save_run().
3. Ensuite, en utilisant la classe php firephp, nous transmettons un lien vers les données de profilage à la partie client
4. Dans la console Firebug, nous ouvrons les informations dont nous avons besoin
5. Nous nous réjouissons :)

Je voudrais également dire que, bien sûr, ajouter manuellement ces fonctions à vos scripts PHP est formidable. Mais je souhaite que ces informations soient toujours à portée de main pendant le développement, et ne finissent pas sur les serveurs de production. Nous résolvons ce problème comme suit :

Dans nos projets, dans presque tous les scripts, un fichier de travail avec un chargeur de classe, des fonctions de connexion et d'autres éléments nécessaires est connecté au début. Par conséquent, nous avons inclus l’inclusion du profilage dans ce fichier. Et afin de pouvoir activer/désactiver le mode débogage à volonté, nous avons ajouté une vérification de la constante de configuration, et nous avons en outre intégré ces vérifications dans certaines balises méta qui sont automatiquement supprimées lors de la construction du projet. Il en va de même pour la désactivation du profilage et l'écriture d'informations dans les en-têtes à l'aide de Firephp - ces tâches sont résolues par une fonction, appelée à la fin de chaque script PHP et également enveloppée dans des balises méta. Cela ressemble à ceci :

// Les constantes suivantes sont écrites dans le fichier de configuration de l'application

/** Mode de fonctionnement de l'environnement * */
définir("APPLICATION_ENV" , "dev" ); // développement - débogage | pro-production
/** Chemin vers le profileur */
définir("XHPROF_ROOT" , __DIR__ . "/ExtProcs/debug/xhprof-0.9.2");

/***************************************************************************************
* Ensuite, dans le fichier chargé au début de chaque script, on lance le profilage
* DEV_START et DEV_END sont nos balises méta, tout entre elles est découpé lors de l'assemblage
***************************************************************************************/

//-- DEV_START
//-- en mode débogage, nous connectons les bibliothèques de débogage

// Charger Firephp
require_once(__DIR__ . "/includes/ExtProcs/debug/firephp/FirePHP.class.php");
//-- charge le profileur
"/xhprof_lib/utils/xhprof_lib.php");
require_once(XHPROF_ROOT. "/xhprof_lib/utils/xhprof_runs.php");
// Initialise le profilage avec les indicateurs nécessaires. Description détaillée des drapeaux
// peut être trouvé sur php.net/manual/ru/xhprof.constants.php
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
}
//-- DEV_END

// Eh bien, cette fonction est appelée à la fin de chaque script
// Son appel est également encapsulé dans DEV_START et DEV_END

/**
* Créez un lien vers le résultat du profilage et affichez-le dans la console
*/
fonction dev_boot_Down() (
si (APPLICATION_ENV === "dev" ) (
// Initialise l'instance Firephp
$firephp = FirePHP::getInstance(true);
// Désactive le profilage et enregistre les données
$xhprof_data = xhprof_disable();
$xhprof_runs = nouveau XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_testing" );
// Créez un lien vers les données de profilage et écrivez-le dans la console
$lien = "http://" . $_SERVER["HTTP_HOST" ] . "/includes/ExtProcs/debug/xhprof-0.9.2/xhprof_html/index.php?run=($run_id)&source=xhprof_testing\n";
$firephp->info($link, "profilage des données" );
}
}

* Ce code source a été mis en évidence avec Source Code Highlighter.

Je n’entrerai pas dans les détails de l’installation de ces extensions, car tout est simple ici. Je ne parlerai que de certains aspects de la configuration. xhproof n'a qu'une seule variable de configuration - xhprof.output_dir, qui pointe vers le dossier dans lequel les données de profilage seront enregistrées. Par conséquent, assurez-vous que l'utilisateur sous lequel les scripts PHP sont exécutés dispose des droits d'écriture sur le répertoire spécifié. Alors écrivez quelque chose comme ceci dans votre php.ini :

extension=xhprof.so
xhprof.output_dir="/var/tmp/xhprof"

C'est également une bonne idée d'installer quelque chose comme dot ou Graphviz pour dessiner des graphiques d'appels. J'ai Graphviz sur MacOS X.

Après avoir effectué les procédures décrites ci-dessus, nous avons pu à tout moment ouvrir et consulter le profilage de n'importe lequel de nos scripts directement dans le navigateur.

Le profilage d'application est la collecte de données sur la vitesse d'exécution de diverses sections de programme (fichiers et fonctions). Il existe de nombreux outils de profilage PHP, mais tous les outils ne sont pas adaptés pour effectuer des analyses directement sur un site de production.

XHProf et son fork Tideways est un profileur pratique et simple qui peut collecter efficacement des statistiques sur le fonctionnement d'une application sans pratiquement aucune réduction de la vitesse de votre application (ou de votre site Web).

Pourquoi un code de profil ?

Si l'application commence à fonctionner lentement (lire « le site a commencé à ralentir »), le profilage vous permettra de savoir quelle partie est la plus lente. Le résultat du profilage est généralement une liste de fonctions exécutées ainsi que leur durée d'exécution.

Le profilage du code doit venir en premier dans le processus d'optimisation des applications. Tout le reste ne serait que conjecture et très probablement faux. Vous devez savoir exactement ce qui cause les problèmes et les « freins ».

Le profilage est une procédure permettant de collecter et d'organiser des statistiques sur le temps d'exécution du code. Il ne s’agit pas d’un processus d’optimisation ou de modification de programme. Le résultat de ce processus est généralement un rapport détaillé sur les composants du programme et les statistiques de performances des fonctions.

C’est exactement pour cela que la solution XHProf a été développée. Il est conçu pour fonctionner sur de vrais sites Web. L'idée principale de ce profileur est de créer une charge minimale sur l'application, tout en collectant toutes les données nécessaires sur la vitesse de fonctionnement. La solution a été développée par des spécialistes de Facebook.

Comment connecter automatiquement le profileur php ?

Nos spécialistes ont travaillé dur et ont rendu ce processus complètement automatisé.
Il vous suffit de vous connecter, de sélectionner le domaine souhaité dans l'onglet « Domaines », de cliquer sur l'icône « PHP.INI + PHP Profiler » et de cocher la case « Domain Profiler ».

L'activation de cette fonctionnalité peut prendre un certain temps, généralement pas plus de 10 minutes.

Pour les versions PHP 5.2, 5.3, 5.4, 5.5, 5.6, 7.0, nous utilisons le profileur XHProf, pour les versions PHP 7.1 et supérieures, nous utilisons le profileur Tideways.

Une fois activé, sur chaque page de votre site traitée par PHP, un bloc spécial avec des liens vers le fichier de rapport sera intégré en bas de celui-ci (le lien ressemblera à ceci :

Nom de domaine.com/xhprof-master/xhprof_html/index.php?run=XXXXXXXXXXXX&source=someapp)

Et voici à quoi ressemblera le fichier de rapport :

Le tableau contient une liste des fonctions exécutées sur une seule page avec des informations supplémentaires :

• Appels - nombre et pourcentage d'appels de fonction
• Incl. Wall Time - temps d'exécution d'une fonction avec des fonctions imbriquées
• Hors. Wall Time - temps d'exécution de la fonction sans fonctions imbriquées
• Incl. CPU - temps processeur avec fonctions imbriquées
• Hors. CPU - temps processeur sans fonctions imbriquées
• Incl. MemUse - consommation de mémoire avec fonctions imbriquées
• Hors. MemUse - consommation de mémoire sans fonctions imbriquées
• Incl. PeakMemUse - consommation de mémoire maximale avec fonctions imbriquées
• Hors. PeakMemUse - consommation de mémoire maximale sans fonctions imbriquées

Il convient de noter que le rapport construit à l'aide des marées peut être légèrement différent visuellement de ce rapport, mais l'essence ne change pas.

Rapports graphiques

Les sections du code gourmandes en ressources sont surlignées en jaune (moyen) et rouge (le plus lourd). Ce sont ces sections de code qui utilisent beaucoup de ressources par rapport au reste du programme. Il peut s'agir d'une fonction lente ou de plusieurs appels à une fonction rapide. Dans notre exemple, nous voyons que la fonction mysqli_multi_query() est marquée en rouge car elle s'exécute la plus lentement.

Rapports agrégés

L'interface XHProf vous permet également d'afficher les informations globales de plusieurs rapports à la fois. Pour ce faire, run_id est passé séparé par des virgules :

Nom de domaine.com/xhprof-master/xhprof_html/index.php?run=XXXXXXXXXXXX,YYYYYYYYYYYY&source=someapp

Caractéristiques techniques

L'inclusion automatique du profileur est implémentée à l'aide des directives auto_append_file et auto_prepend_file, qui connectent deux fichiers php exécutables :

— auto_append_file initialise l'objet de collecte de statistiques et commence son travail ;

— auto_prepend_file complète la collecte des statistiques et génère un fichier de rapport avec des statistiques (au format JSON) ;

Si exit() ou die() est appelé pendant l'exécution de votre script, auto_prepend_file ne sera pas exécuté. le fichier de statistiques ne sera pas généré et un bloc avec des liens vers le fichier de rapport ne sera pas inclus au bas de la page.

1. Ainsi, accéder à n'importe quelle page traitée par php déclenchera la création d'un nouveau fichier de rapport, nous recommandons donc de désactiver le profileur après la collecte des statistiques (généralement quelques heures), afin d'éviter de dépasser le quota du disque, qui peut être épuisé après la génération d'un un grand nombre de rapports!
2. Important : le profileur ne fonctionnera que si le site est connecté au serveur via un chemin standard, par des moyens automatiques (c'est-à-dire en utilisant le panneau de contrôle de l'hébergement), sinon vous devez contacter le support technique d'Hostland pour configurer le profileur.
3. En mode automatique, le profileur se connecte uniquement au nom de domaine principal ; le profileur n'est pas automatiquement connecté aux sous-domaines.
4. En mode automatique, le profileur collecte des statistiques uniquement pour les scripts avec l'extension .php et .php5
5. Il n'est pas possible de garantir un fonctionnement ininterrompu du site après la connexion du profileur PHP. Par conséquent, si le site ne fonctionne pas correctement lorsque le profileur est activé, il doit être désactivé et le profilage doit être poursuivi par d'autres moyens.

Résumons-le

Nous espérons que cet outil vous aidera à rendre vos sites encore plus rapides sur l'hébergement Hostland.

L'article utilise partiellement les documents de l'utilisateur Den Golotyuk publiés sur le site Web.

À l'aide de systèmes de profilage, vous pouvez collecter des informations sur les fonctions du code PHP qui consomment plus de temps CPU et de RAM, c'est-à-dire identifier les endroits les plus lents et les plus gourmands en mémoire dans un programme PHP.

xhprof

XHProf - Profileur PHP développé par Facebook.

Installation:

Aptitude installer php-pear pecl installer xhprof-0.9.4 echo "extension=xhprof.so" > /etc/php5/mods-available/xhprof.ini ln -s /etc/php5/mods-available/xhprof.ini /etc /php5/conf.d/xhprof.ini apachectl redémarrage

Les fichiers nécessaires au travail se trouvent dans le répertoire /usr/share/php. Mais pas tout, mais uniquement avec du code PHP. Pour un affichage normal des rapports, jquery et css sont requis. Ils peuvent être obtenus depuis le dépôt github :

Clone Git https://github.com/facebook/xhprof.git

Après cela, ajoutez la ligne au code du script PHP à l'endroit où la collecte des données doit commencer :

Xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

Les paramètres de collecte des données sont indiqués entre parenthèses. Dans ce cas, des données seront collectées sur la charge du processeur et l'utilisation de la RAM. Une autre option est possible XHPROF_FLAGS_NO_BUILTINS lorsqu'elles sont utilisées, les données sur les fonctions intégrées ne sont pas collectées.

$xhprof_data = xhprof_disable(); include_once "xhprof_lib/utils/xhprof_lib.php"; include_once "xhprof_lib/utils/xhprof_runs.php"; $xhprof_runs = nouveau XHProfRuns_Default(); $run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_test"); echo "Rapport : http://domain.tld/xhprof_html/index.php?run=$run_id&source=xhprof_test" ; écho "\n" ;

En ligne $run_id Les guillemets indiquent le nom du profil, qui peut être défini arbitrairement.

Le résultat traité ressemble à ceci :

Si vous spécifiez le paramètre XHPROF_FLAGS_NO_BUILTINS, force est de constater que le nombre d'appels de fonctions est considérablement réduit :

Le tableau fournit les informations suivantes :

Appels- nombre d'appels de fonction,
L'heure du mur- la durée totale de fonctionnement de la fonction, y compris le temps passé à attendre une réponse des ressources externes,
CPU- combien de temps a été consacré au traitement des fonctions,
Utilisation de la mémoire- combien de RAM a été utilisée,
Utilisation de PeakMem- consommation maximale de mémoire.

Les modificateurs sont :

Incl.- inclusif - prise en compte des appels vers d'autres fonctions depuis cette fonction,
Hors.- exclusif - hors appels de fonction.

De plus, au-dessus du tableau se trouvent des informations sur le temps total de traitement, la mémoire utilisée et le nombre d'appels de fonction.

Aussi XHProf vous permet de créer des rapports différentiels entre deux exécutions, indiqués par des couleurs rouge et verte. Grâce à ces rapports, vous pouvez obtenir une image claire des améliorations après chaque modification de code.

Pour obtenir un tel rapport, vous devez utiliser un lien comme celui-ci :

http://domain.tld/xhprof_html/index.php?run1=run_id1&run2=run_id2&source=xhprof_test

Où run_id1 Et run_id2- les identifiants de lancement.

Si vous installez Visualisation graphique:

Aptitude à installer graphviz

Il existe également des interfaces Web tierces pour le profileur php xhprof qui utilisent des bases de données :

xDebug

xDebug- Débogueur de code PHP avec capacité de profilage, écrit par Derick Rethans.

Installation:

Miam, installez php5-xdebug

Ensuite on édite la config :

Nano /etc/php5/mods-available/xdebug.ini

en y ajoutant les lignes :

Xdebug.profiler_enable = 1 xdebug.profiler_aggregate = Sur xdebug.profiler_output_dir = /tmp

Ici, nous activons le profileur PHP et spécifions le répertoire dans lequel stocker les profils. Les profils sont créés avec des noms comme cachegrind.out.*

Il existe un client Web webgrind : https://github.com/jokkedk/webgrind. Cela ne fonctionne pas très rapidement, mais cela vous permet de visualiser rapidement de petits profils. En fait, c'est le code PHP qui doit être cloné depuis github :

Clone Git https://github.com/jokkedk/webgrind.git

un répertoire sera créé Webgrind, que vous devez copier dans le répertoire de n’importe quel site Web et y accéder depuis le navigateur. Ensuite, pour que le traçage dans le fichier de configuration fonctionne dans Debian config.php vous devez corriger le chemin d'accès au fichier exécutable visualisation graphique. Ça devrait ressembler à ça:

Statique $dotExecutable = "/usr/bin/dot";

De plus, vous pouvez ajuster le fuseau horaire :

Statique $defaultTimezone = "Europe/Moscou" ;

Dans l'en-tête, vous pouvez sélectionner un profil et cocher la case pour prendre en compte les fonctions intégrées. Le tableau lui-même indique les fonctions, le nombre d'appels, la durée de fonctionnement de la fonction elle-même et le temps d'attente compris. Pour approfondir les fonctions, cliquez simplement sur la flèche triangulaire. Dans mon cas, avec des profils assez volumineux (à partir de plusieurs mégaoctets), l'attente du résultat était inutilement longue. Il est probablement préférable d'utiliser des programmes de visualisation locaux pour des profils assez volumineux.

Le graphique pourrait ressembler à ceci :

noter que Webgrind ne doit pas être utilisé sur les serveurs de production, car aucune autorisation n'est fournie, mais il y a accès au code du fichier php. Si nécessaire, utilisez au moins l'autorisation Apache de base.

Il existe également des programmes d'analyse de profils pour Linux :

À propos du profilage

Les données de profil peuvent vous aider à améliorer votre application, c'est-à-dire à atteindre certains objectifs, par exemple réduire la consommation de mémoire, réduire le temps de génération des pages, etc.

Les informations du profil sont le point de départ de l'optimisation : elles indiquent combien de temps il faut pour générer le résultat, combien de mémoire est utilisée et combien d'appels de fonction sont effectués. Avec des données plus détaillées, vous pouvez améliorer ces mesures.

Par exemple, si vous utilisez un framework, l'utilisation de certaines fonctions du framework peut conduire à des appels à plusieurs fonctions de base. Si vous lisez certaines données plusieurs fois, cela peut valoir la peine de stocker le résultat dans une variable.

Le profileur peut également vous aider à comprendre où utiliser la mise en cache du code PHP, par exemple en utilisant APCU ou memcaché.

Tout d’abord, il convient d’optimiser les fonctions qui nécessitent le plus de temps d’exécution. Une fois que tout est optimisé et qu’il semble qu’il n’y a plus rien à améliorer, cela vaut la peine de trier les fonctions par nombre d’appels et de travailler à le réduire. Même si PHP est rapide, cela vaut la peine de se demander si vous devez appeler des fonctions aussi souvent ?

Si vous rencontrez les situations suivantes, vous devriez envisager la mise en cache :

• Les fonctions immuables sont appelées dans une boucle,
• Certains contenus sont générés deux fois,
• Un contenu qui ne change pas est généré à chaque fois,
• Le contenu est généré même s'il n'est pas utilisé.

Vous ne devez pas tout mettre en cache, car la mémoire est également une ressource précieuse. Mettez en cache les données auxquelles vous accédez en permanence. De plus, la mise en cache n’a pas de sens si elle gaspille plus de ressources qu’elle n’en économise.

En plus de la mise en cache dans le code, n'oubliez pas la mise en cache à l'aide du serveur Web (), ainsi que côté client. Si vous utilisez les bons en-têtes, de nombreuses requêtes peuvent être résolues avant même qu'elles n'atteignent le serveur.