Meny
Är gratis
registrering
Hem  /  Installation och konfiguration/ Imaginära profiler php. Profilering och felsökning av php-applikationer med xhprof

Imaginära profiler php. Profilering och felsökning av php-applikationer med xhprof

Profilering av PHP-kod

Förr eller senare står var och en av oss inför äldre kod och dess optimering. Debugger och profiler i en sådan situation - bästa medhjälpare programmerare. För de som jobbar med PHP, tack vare Derick Rethans, finns det ett bra verktyg - xDebug. Det finns mycket information om xDebug även i runet, så den här artikeln kommer inte att handla om det.

Efter att ha snubblat på omnämnandet av en profiler för PHP, tänkte jag genast på xDebug (jag har länge glömt om patentskyddade verktyg från Zend), men den här gången hade jag fel - vi kommer att prata om XHProf.
XHProf

Denna profiler utvecklades speciellt för Facebook och källa det öppnades i mars 2009.

Installationen gick snabbt och smidigt.
wget pecl.php.net/get/xhprof-0.9.2.tgz
tar xvf xhprof-0.9.2.tgz
cd xhprof-0.9.2 / extension /
phpize
./konfigurera && gör && gör installera
cd /usr/local/etc/php.d/
vim xhprof.ini
cd / usr / lokal /
vim header.php
vim footer.php
vim etc / php.ini
/etc/init.d/php-fpm starta om
cp vhost.conf.template prof.my.conf
sed -i s / site / prof / prof.my.conf
vim prof.my.conf
/etc/init.d/nginx starta om

Låt oss analysera de nämnda konfigurationerna

Xhprof.ini
extension = / usr / local / lib / php / extensions / no-debug-non-zts-20090626 / xhprof.so
xhprof.output_dir = "/ hem / max / www / profil /"

Prof.my.conf - nginks config - den mest standard.

Server (
lyssna 80;
servernamn prof.my;
teckenuppsättning utf8;

Root /usr/local/src/xhprof-0.9.2/xhprof_html;
plats / (
index index.php;
}

Plats ~ \ .php $ (
fastcgi_pass 127.0.0.1:12000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/local/src/xhprof-0.9.2/xhprof_html/$fastcgi_script_name;
inkluderar fastcgi_params;

/Usr/local/src/xhprof-0.9.2/xhprof_html innehåller PHP-källor som skapar ett snyggt WEBGUI för profileraren.

Så om de två huvudfilerna:

Header.php


include_once "/usr/local/src/xhprof-0.9.2/xhprof_lib/utils/xhprof_lib.php";
include_once "/usr/local/src/xhprof-0.9.2/xhprof_lib/utils/xhprof_runs.php";
xhprof_enable (XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
}
}

Footer.php
if (isset ($ _ COOKIE ["xhprof"))) (
if (extension_loaded ("xhprof")) (
$ profiler_namespace = "minapp"; // namnutrymme för din applikation
$ xhprof_data = xhprof_disable ();
$ xhprof_runs = ny XHProfRuns_Default ();
$ run_id = $ xhprof_runs-> save_run ($ xhprof_data, $ profiler_namespace);

// url till XHProf UI-bibliotek (ändra värdnamn och sökväg)
$ profiler_url = sprintf ("http://prof.my/index.php?run=%s&source=%s", $ run_id, $ profiler_namespace);
eko<<Profiler utgång
UT;
}
}

Nu kör vi valfritt PHP-skript via webben och ser i det övre vänstra hörnet en länk till utdata från profilern - det är detta som prof.my-värden skapades för.

Observera - jag använder verifiering för COOKIE! Med denna verifiering kan du säkert använda profilern på produktionsservern - på verklig data och på verklig belastning.

Profilers webbgränssnitt visar etiketter med information om varje funktion och rapporterar följande information:

  • Antal anrop till varje funktion
  • Wall-time, den tid som ägnas åt att utföra funktioner (inklusive att vänta på svar från sockets, filsystem, etc.).
  • CPU-tid, tid som spenderas på att utföra funktioner (exklusive väntan på svar från sockets, filsystem, etc.).
  • Minnesanvändning
  • Maximal minnesanvändning

Det är möjligt att sortera tabellen efter någon av parametrarna

Information om varje funktion är uppdelad i ytterligare två typer Inkluderande och Exklusiv. Inklusive inkluderar siffrorna som används av barnsamtal, medan Exclusive inte gör det. Det är också möjligt att, genom att klicka på funktionens namn, endast se information om den och de funktioner som den anropades från och vilka som anropades till den.

Om GraphViz är installerat på systemet kommer profileraren att rita en samtalsgraf åt dig.

P.S. Utan att bryta traditioner: detta är mitt första inlägg om habr.

UPD: posta om i PHP.

Med hjälp av profileringssystem kan du samla information om vilka funktioner i php-kod som förbrukar mer processortid och RAM, det vill säga identifiera de långsammaste och mest minneskrävande platserna i ett php-program.

xhprof

XHProf - PHP-profiler utvecklad av Facebook.

Installation:

Aptitude installera php-pear pecl installera 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 omstart

Filer som krävs för arbete finns i katalogen / usr / share / php... Dock inte alla, utan bara med php-kod. Det kräver jquery och css för att visa rapporterna korrekt. De kan erhållas från förvaret på github:

Git-klon https://github.com/facebook/xhprof.git

Lägg sedan till raden i php-script-koden på den plats där datainsamlingen ska börja:

Xhprof_enable (XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

Parametrar för datainsamling anges inom parentes. I det här fallet kommer data att samlas in om belastningen på processorn och om användningen av RAM. Ytterligare en parameter är möjlig XHPROF_FLAGS_NO_BUILTINS vid användning av vilka data om inbyggda funktioner som inte samlas in.

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

I kö $ run_id citattecken anger namnet på profilen, som kan ställas in godtyckligt.

Det bearbetade resultatet ser ut så här:

Om du anger parametern XHPROF_FLAGS_NO_BUILTINS, då kan du se att antalet funktionsanrop har minskat avsevärt:

Tabellen ger följande information:

Samtal- antalet funktionsanrop,
Väggtid- den totala drifttiden för funktionen, inklusive väntetiden för svar från externa resurser,
CPU- hur mycket tid spenderades på bearbetningsfunktioner,
MemUse- hur mycket RAM som användes,
PeakMemUse- maximal minnesförbrukning.

Modifierarna är:

Inkl- inklusive - med hänsyn till anrop av andra funktioner från denna funktion,
Exkl- exklusiv - exklusive funktionsanrop.

Dessutom presenteras information om total behandlingstid, använt minne och antal funktionsanrop ovanför tabellen.

Också XHProf låter dig bygga differentialrapporter mellan två körningar, som indikeras i rött och grönt. Med dessa rapporter kan du få en tydlig bild av förbättringarna efter varje kodändring.

För att få en sådan rapport måste du använda en länk i formuläret:

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

var run_id1 och run_id2- lanseringsidentifierare.

Om du installerar Graphviz:

Aptitude installera graphviz

Även för php profiler xhprof finns det tredjeparts webbgränssnitt som använder databaser:

xDebug

xDebugär en profilerande PHP-kodfelsökning skriven av Derick Rethans.

Installation:

Yum installera php5-xdebug

Sedan redigerar vi konfigurationen:

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

lägger till raderna till det:

Xdebug.profiler_enable = 1 xdebug.profiler_aggregate = På xdebug.profiler_output_dir = / tmp

Här slår vi på PHP-profileraren och anger i vilken katalog profilerna ska placeras. Profiler skapas med namn som cachegrind.out. *

Det finns en webgrind-webbklient: https://github.com/jokkedk/webgrind. Det fungerar inte särskilt snabbt, men det låter dig snabbt se små profiler. Faktum är att detta är PHP-kod som måste klonas från github:

Git-klon https://github.com/jokkedk/webgrind.git

en katalog kommer att skapas webgrind, som du måste kopiera till katalogen på vilken webbplats som helst och komma åt den från webbläsaren. Vidare, så att grafen i konfigurationsfilen fungerar i Debian config.php du måste korrigera sökvägen till den körbara filen graphviz... Det ska se ut så här:

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

Dessutom kan du korrigera tidszonen:

Static $ defaultTimezone = "Europa / Moskva";

I rubriken kan du välja en profil och markera rutan om du ska ta hänsyn till inbyggda funktioner. I själva tabellen kan du se funktionerna, antalet samtal, drifttiden för själva funktionen och tiden med hänsyn till väntetiden. För att gå djupare in i funktionerna klickar du bara på den triangulära pilen. I mitt fall, med tillräckligt stora profiler (från flera megabyte), var förväntningarna på resultatet onödigt höga. För tillräckligt stora profiler är det förmodligen bättre att använda lokala tittarprogram.

Grafen kan se ut så här:

anteckna det webgrind bör inte användas på produktionsservrar, eftersom ingen behörighet ges, men samtidigt finns det tillgång till koden för filerna i php. Använd åtminstone Apache grundläggande behörighet om det behövs.

Det finns också program för att analysera profiler som under Linux:

Om profilering

Profildata kan hjälpa dig att förbättra din applikation, det vill säga uppnå vissa mål, till exempel lägre minnesförbrukning, minska sidgenereringstiden och så vidare.

Informationen i profilen är utgångspunkten för optimering: den berättar hur länge resultatet genereras, hur mycket minne som används och hur många funktionsanrop som görs. Med mer detaljerad information kan du förbättra dessa mätvärden.

Om du till exempel använder ett ramverk kan användning av några av ramverkets funktioner resultera i att flera grundläggande funktioner anropas. Om du läser vissa data flera gånger kan det vara värt att spara resultatet till en variabel.

Profileraren kan också hjälpa dig att förstå var du kan använda PHP-cache, till exempel med APCu eller memcachad.

Först och främst är det värt att optimera de funktioner som tar mest tid att utföra. Efter att allt är optimerat och det verkar som att det inte finns något mer att förbättra är det värt att sortera funktionerna efter antalet samtal och arbeta med att sänka det. Även om PHP är snabbt är det värt att överväga om du behöver anropa funktioner så ofta?

När du stöter på följande situationer är det värt att överväga cachelagring:

  • Oföränderliga funktioner kallas inuti slingan,
  • En del innehåll genereras två gånger,
  • Innehåll som inte förändras genereras varje gång,
  • Innehåll genereras även om det inte används.

Du bör inte cache allt eftersom minne också är en värdefull resurs. Cachelagra den data du ständigt kommer åt. Dessutom är cachning inte meningsfullt om cachning slösar mer resurser än det sparar.

Förutom att cachelagra din kod, glöm inte att cachelagra med hjälp av webbservern (), såväl som på klientsidan. Genom att använda rätt rubriker kan många förfrågningar lösas innan de når servern.

Med tiden ställs alla PHP-programmerare inför problemet med dålig prestanda för sin applikation. Detta kan vara en långsam laddning av en specifik sida eller ett för långt svar från API:et. Och ibland är det ganska svårt att förstå vad som är orsaken till bromsarna? Ibland inträffar svårare situationer: på produktionsservern är api väldigt långsam, men i montern där utvecklingen äger rum är allt bra. Och ta reda på vad som går fel. Att felsöka på en produktionsserver är en extrem förtvivlan, som naturligtvis bäst lämnas okontrollerad.

Det är för dessa situationer som speciella verktyg som kallas applikationsprofiler uppfanns. I PHP-världen spelas denna roll av såväl xDebug som xhprof. xhprof är ett lättare, enklare och mer flexibelt verktyg och är därför att föredra. Intressant nog utvecklades xhprof av facebook redan 2009, men det finns fortfarande inget officiellt php7-stöd från dem och kommer inte att vara längre sedan facebook bytte till HHVM. Men tack vare den stora gemenskapen av php-utvecklare har det dykt upp en gaffel som stöder php7, vars installation inte orsakar några svårigheter.

Installation

Först måste du faktiskt installera xhprof:

Git-klon 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

Tillägg = xhprof.so xhprof.output_dir = "/ var / tmp / xhprof"

Mappen / var / tmp / xhprof måste ha skrivbehörighet, eftersom profileringsresultat kommer att sparas där.

Du kan ladda om PHP-FPM och kontrollera om tillägget är installerat. Det är banalt, det kan göras med utgången av funktionen phpinfo ();

xhprof är installerat kan du använda det. xhprof-paketet innehåller ett mycket användarvänligt gränssnitt för att analysera profileringsrapporter. xhprof låter dig bygga rapporter, både i text och grafisk form. Installationsmappen xhprof innehåller xhprof_html och xhprof_lib som vi behöver. Mapp Xhprof_html - Ger åtkomst till GUI. xhprof_lib är ett bibliotek för att visa och analysera kod. Det är tillrådligt att flytta hela xhprof-mappen till / var / www / xhprof och konfigurera en virtuell värd för den, till exempel xhprof.loc. Exempel för nginx:

Server (lyssna 80; servernamn xhprof.loc; charset utf-8; root / var / www / xhprof / xhprof_html; index index.php; plats / (try_files $ uri $ uri / /index.php?q=$uri&$args ;) plats ~ \ .php (fastcgi_pass 127.0.0.1:9000; fastcgi_split_path_info ^ (. + \. php) (/.+) $; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; inkludera fastcgi_params;))

Du måste också komma ihåg att uppdatera din hosts-fil. Nu, när vi anger URL:en xhprof.loc i webbläsaren, kommer vi att tas till profilerarens webbgränssnitt, där filerna som genereras av den kommer att nås.

Nu kan du börja profilera din kod direkt.

För att aktivera profileraren, använd funktionen xhprof_enable (), som tar följande flaggor som indata:

  • XHPROF_FLAGS_CPU - för att fixa processorstatistik;
  • XHPROF_FLAGS_MEMORY - för minne;
  • XHPROF_FLAGS_NO_BUILTINS - för att ignorera inbyggda funktioner.

Använd funktionen xhprof_disable () för att inaktivera profileraren. För enkelhetens skull, låt oss skriva två skript header.php och footer.php som utför dessa funktioner. header.php ingår i början av det profilerade skriptet och footer.php är i slutet. footer.php handlar också om att spara profileringsdata.

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/xhpprof_runs.php xh (prof_runs.php xh) XHPROF_FLAGS_CPU);) footer.php: if (extension_loaded ("xhprof")) ($ profilerNamespace = "PROFILED_SCRIPT_NAME_ HERE"; $ xhprofData = xhprof_shprofRunIsable (); ($ xhprofData, $ profilerNamespace);)
Användande

Efter att ha kopplat header.php och footer.php till det profilerade skriptet kan du börja: när det profilerade skriptet körs, kommer en fil att skapas som kommer att sparas i katalogen / var / tmp / xhprof som innehåller information om skriptets funktion. När du öppnar webbgränssnittet xhprof.loc kommer den här genererade filen att vara tillgänglig:


När du öppnar profileringsfilen visas detaljerad information om applikationens funktion, hela samtalsstacken:


Vad kolumnerna betyder:

  • Samtal- antal och procentandel av funktionsanrop;
  • Inkl. Väggtid- exekveringstid för en funktion med kapslade funktioner;
  • Exkl. Väggtid- exekveringstid för en funktion utan kapslade funktioner;
  • Inkl. CPU- processortid med kapslade funktioner;
  • Exkl. CPU- CPU-tid utan kapslade funktioner;
  • Inkl. MemUse- Minnesförbrukning med kapslade funktioner;
  • Exkl. MemUse- minnesförbrukning utan kapslade funktioner;
  • Inkl. PeakMemUse- maximal minnesförbrukning med kapslade funktioner;
  • Exkl. PeakMemUse- maximal minnesförbrukning utan kapslade funktioner.

Om du följer länken kommer du att se ett vackert samtalsträd med en visuell indikation på den mest hämmade koden. Om detta inte hände, måste du troligen installera graphviz-biblioteket:

Apt-get installera graphviz

Ett exempel på en plottad graf:

I mitt fall är flaskhalsen interaktionen med databasen.


Använda xhprof på en produktionsserver

Inledningsvis utvecklades xhprof specifikt för att profilera kod i strid, på produktionsservrar. Det finns helt enkelt inget annat gratis och effektivt verktyg för att profilera php7-kod i strid, så xhprof har inga konkurrenter. Specifikt har jag erfarenhet av att använda xhprof på en produktionsserver som behandlar en miljon förfrågningar per dag. Den använder php7 och inga problem har hittats ännu. Men xhprof körs inte för varje begäran - för många profileringsfiler skulle genereras. Min profiler startar endast om begäran innehåller rubriken "XHPROF_ENABLE" och den är satt till true. Du kan också använda en annan strategi, till exempel kör profileraren slumpmässigt med en sannolikhet på till exempel 1/1000. Då blir bilden tillräckligt tydlig också.


Produktion

Även om xhprof inte officiellt stöds för php7, är det fortfarande ett oumbärligt verktyg för php-utvecklare.

En tillägg till PHP som heter Xdebug är tillgänglig för att hjälpa till med profilering av PHP-applikationer, såväl som runtime-felsökning. När profilern körs skrivs utdata till en fil i ett binärt format som kallas "cachegrind". Applikationer finns tillgängliga på varje plattform för att analysera dessa filer. Inga ändringar av applikationskoden är nödvändiga för att utföra denna profilering.

För att aktivera profilering, installera tillägget och justera php.ini-inställningarna. Vissa Linux-distributioner kommer med standardpaket (t.ex. Ubuntus php-xdebug-paket). I vårt exempel kommer vi att köra profilen valfritt baserat på en begäran-parameter. Detta tillåter oss att hålla inställningarna statiska och aktivera profileraren endast efter behov.

# php.ini-inställningar # Sätt till 1 för att aktivera det för varje begäran xdebug.profiler_enable = 0 # Låt oss använda en GET/POST-parameter för att aktivera profilern xdebug.profiler_enable_trigger = 1 # GET/POST-värdet vi kommer att skicka ; tomt för något värde xdebug.profiler_enable_trigger_value = "" # Mata ut cachegrind-filer till / tmp så vårt system rensar upp dem senare xdebug.profiler_output_dir = "/ tmp" xdebug.profiler_output_name = "cachegrind.out.% p"

Använd sedan en webbklient för att göra en begäran till din applikations URL som du vill profilera, t.ex.

Http://example.com/article/1?XDEBUG_PROFILE=1

När sidan bearbetas kommer den att skriva till en fil med ett namn som liknar

/tmp/cachegrind.out.12345

Som standard är numret i filnamnet det process-id som skrev det. Detta är konfigurerbart med inställningen xdebug.profiler_output_name.

Observera att det kommer att skriva en fil för varje PHP-begäran/process som exekveras. Så om du till exempel vill analysera ett formulärinlägg kommer en profil att skrivas för GET-förfrågan att visa HTML-formuläret. Parametern XDEBUG_PROFILE måste skickas till den efterföljande POST-begäran för att analysera den andra begäran som behandlar formuläret. Därför vid profilering är det ibland lättare att köra curl för att POSTA ett formulär direkt.

Analysera output

När den väl har skrivits kan profilcachen läsas av en applikation som eller Webgrind. PHPStorm, en populär PHP IDE, kan också visa denna profileringsdata.

KCachegrind kommer till exempel att visa information inklusive:

  • Funktioner utförda
  • Samtalstid, både sig själv och inklusive efterföljande funktionsanrop
  • Antal gånger varje funktion anropas
  • Ring grafer
  • Länkar till källkod

Vad du ska leta efter

Uppenbarligen är prestandajustering mycket specifik för varje applikations användningsfall. I allmänhet är det bra att leta efter:

  • Upprepade anrop till samma funktion som du inte skulle förvänta dig att se. För funktioner som bearbetar och frågar efter data kan dessa vara utmärkta möjligheter för din applikation att cache.
  • Långsamtgående funktioner. Var spenderar applikationen mest tid? den bästa vinsten i prestandajustering är att fokusera på de delar av applikationen som förbrukar mest tid.

Notera: Xdebug, och i synnerhet dess profileringsfunktioner, är mycket resurskrävande och saktar ner PHP-exekveringen. Det rekommenderas att inte köra dessa i en produktionsservermiljö.

FirePHP är ett tillägg för firebug, som i kombination med sin lilla php-klass låter dig sända data från php, till exempel var_dump och annan felsökningsinformation, till firebug-konsolens headers och inte skräpar ner sidorna och bryter inte sönder applikationens logik på något sätt.Officiell webbplats: http://firephp.org/.

Huvudtanken.

Den allmänna profileringsalgoritmen är som följer:
  1. I början av sidan, aktivera profilering med xhprof_enable ()
  2. I slutet av sidan, inaktivera profilering med xhprof_disable () och spara insamlad data med save_run ()
  3. Därefter, med hjälp av firephp php-klassen, överför vi länken till profileringsdata till klientsidan
  4. I firebug-konsolen "och öppna den information vi behöver
  5. Vi är glada :)
Jag skulle också vilja säga att det naturligtvis är bra att manuellt lägga till dessa funktioner i dina php-skript. Men jag vill att denna information alltid ska finnas till hands under utvecklingen och samtidigt inte komma till stridsservrarna. Vi löser detta problem enligt följande:

I våra projekt, i nästan alla skript, är en arbetsfil med en klassladdare, anslutningsfunktioner och andra nödvändiga saker ansluten i början. Därför flyttade vi inkluderingen av profilering till den här filen. Och för att kunna slå på/stänga av felsökningsläget efter behag lade vi till en kontroll för en konfigurationskonstant, plus att vi lindade in dessa kontroller i några metataggar som automatiskt tas bort när projektet byggs. Detsamma gäller för att inaktivera profilering och skriva information till rubriker med firephp - dessa uppgifter löses av en funktion som anropas i slutet av varje php-skript och som också är insvept i metataggar. Det ser ut så här:

// Dessa konstanter är skrivna i programmets konfigurationsfil

/ ** Miljödriftläge ** /
definiera ("APPLICATION_ENV", "dev"); // dev - debug | pro - produktion
/ ** Sökväg till profilerare * /
definiera ("XHPROF_ROOT", __DIR__. "/ExtProcs/debug/xhprof-0.9.2");

/***************************************************************************************
* Därefter kör vi profileringen i filen som laddas i början av varje skript
* DEV_START och DEV_END är våra metataggar, allt mellan dem klipps ut under monteringen
***************************************************************************************/

// - DEV_START
// - i felsökningsläge, anslut felsökningsbiblioteken

// Ladda firephp
require_once (__ DIR__. "/includes/ExtProcs/debug/firephp/FirePHP.class.php");
// - ladda profilern
"/xhprof_lib/utils/xhprof_lib.php");
require_once (XHPROF_ROOT. "/xhprof_lib/utils/xhprof_runs.php");
// Initiera profilering med de obligatoriska flaggorna. Detaljerad beskrivning av flaggor
// finns på php.net/manual/ru/xhprof.constants.php
xhprof_enable (XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
}
// - DEV_END

// Tja, den här funktionen anropas i slutet av varje skript
// Dess anrop är också inkluderat i DEV_START och DEV_END

/**
* Skapa en länk till profileringsresultatet och skicka det till konsolen
*/
function dev_boot_Down () (
if (APPLICATION_ENV === "dev") (
// Initiera firephp-instansen
$ firephp = FirePHP :: getInstance (true);
// Stäng av profilering och spara data
$ xhprof_data = xhprof_disable ();
$ xhprof_runs = ny XHProfRuns_Default ();
$ run_id = $ xhprof_runs-> save_run ($ xhprof_data, "xhprof_testing");
// Skapa en länk till profildata och skriv den till konsolen
$ länk = "http: //". $ _SERVER ["HTTP_HOST"]. "/includes/ExtProcs/debug/xhprof-0.9.2/xhprof_html/index.php?run=($run_id)&source=xhprof_testing\n";
$ firephp-> info ($ länk, "profileringsdata");
}
}


* Den här källkoden markerades med Source Code Highlighter.

Jag kommer inte att gå in på detaljerna för att installera dessa tillägg, eftersom allt är enkelt här. Jag kommer bara att säga om några av inställningspunkterna. Xhproof tillhandahåller endast en konfigurationsvariabel, xhprof.output_dir, som pekar på mappen där profileringsdata kommer att sparas. Se därför till att användaren som php-skripten körs under har skrivbehörighet till den angivna katalogen. Så lägg något så här i din php.ini:


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

Det är inte heller dåligt att sätta något som dot eller Graphviz för att rita samtalsgrafer. Jag har Graphviz under MacOS X.

Efter att ha slutfört ovanstående procedurer kunde vi när som helst öppna och titta på profileringen av något av våra skript direkt i webbläsaren.