Den viste hvordan du installerer og konfigurerer xdebug, og dekket noen grunnleggende funksjoner, som å forbedre utdataene til var_dump()-funksjonen eller skrive ut en anropsstakksporing når du mottar en feilmelding. I den andre delen så vi på denne xdebug-funksjonen som sporing. Sporingen inneholder alle kall til funksjoner og metoder i programmet, oppstartstid, eventuelt minnestørrelse, beståtte og returnerte parametere. En sporingslogg kan hjelpe deg med å forstå kjørebanen til et komplekst program. I stedet for å sette inn feilsøkingskode i programmet, slår du sporing på eller av der det er nødvendig, og bruker deretter verktøy som grep eller dine egne PHP-applikasjoner for å analysere loggfilen.
I denne artikkelen skal vi se på profilering. Ved første øyekast ligner profilering på sporing. Profileringsloggen er ikke ment for mennesker, den er ikke ment for å visualisere flyten til et program, men den gir oss data for statistisk analyse av et program som kjører.
Opprette en profileringslogg
Nedenfor er et kort utdrag fra profileringsloggen generert av xdebug:
fl=php:intern
fn=php::define
106 3Fl=C:\www\drupal\includes\bootstrap.inc
fn=require_once::C:\www\drupal\includes\bootstrap.inc
1 648
cfn=php::define
samtaler=1 0 0
13 6
cfn=php::define
samtaler=1 0 0
18 4
cfn=php::define
samtaler=1 0 0
23 2
Som du kan se kan profileringsloggen ikke leses direkte. Vi vil bruke tilleggsverktøy for å visualisere og analysere innhentede data. Så, profilering viser hvor mange ganger en bestemt linje ble lansert og hvor lang tid lanseringen tok.
Å lage en profileringslogg forringer ytelsen betydelig, på samme måte som å lage en sporingslogg, fordi det er nødvendig å beskrive passasjen til hver linje. Derfor, akkurat som ved sporing, ikke kjør profilering på produksjonsservere... Det er imidlertid tilfeller når profilering må kjøres på et live system. I dette tilfellet, vær forsiktig med å kjøre xdebug samtidig med andre Zend-utvidelser, for eksempel loaders, optimizers eller cacher.
For at xdebug skal begynne å registrere profileringslogger, legg til
Vær oppmerksom på at du ikke kan kjøre profilering ved oppstart ved å kjøre en kommando.
Siden profileringsloggen er ment å leses av analysatorprogrammer, er det ingen tilleggsinnstillinger som lar deg vise tilleggsinformasjon, slik tilfellet er med sporingsloggen. Det er imidlertid noen innstillinger som lar deg konfigurere profilering, lik de vi brukte da vi satte opp sporing.
For det første skriver xdebug profileringsloggen til /tmp-katalogen som standard. Hvis du bruker Windows, må du fikse php.ini, slik:
xdebug.profiler_output_dir="c:\spor"
Som standard overskriver xdebug den eksisterende profileringsloggen. Du kan konfigurere den til å utfylle den eksisterende ved å legge til følgende kommando
i php.ini. Det er tilfeller hvor du ikke ønsker å lage en profileringslogg for alle filer, men samtidig er det problematisk å aktivere profilering under kjøring. I stedet for å slå profilering på og av med jevne mellomrom, legg til kommandoen
xdebug.profiler_enable_trigger=På
i php.ini. Nå kan du slå profilering på og av ved å sende en spesiell GET- eller POST-parameter XDEBUG_PROFILE til et PHP-skript. Dette vil aktivere profilering kun for dette PHP-skriptet. Det er ikke nødvendig å angi verdien til denne parameteren, bare husk å legge denne parameteren til adressen test.php?XDEBUG_PROFILE.
Profileringsloggnavn
Navnet som xdebug tildeler profileringsloggen som standard er "cachegrind.out." pluss prosessidentifikator. Akkurat som i tilfellet med sporingsloggen, kan du endre navnene på loggen ved å legge til de riktige innstillingene til php.ini. Parameternavn xdebug.profiler_output_name. Argumentet er en streng. som kan inneholde forskjellige modifikatorer. De viktigste er nedenfor:
- %p – prosessidentifikator
- %r – tilfeldig tall
- %u - tid
- %H – verdi av $_SERVER["HTTP_HOST"]
- %R – verdi av $_SERVER["REQUEST_URI"]
- %s – navn inkludert full bane, skråstreker konverteres til understrek
Profileringslogganalyse
Som nevnt ovenfor, for å analysere profileringsloggen, kreves det ytterligere programmer for datavisualisering. Alle profileringslogger som xdebug oppretter er i et format som ligner på Cachegrind-formatet. Cachegrind er en profiler som er en del av et kraftigere program kalt Valgrind, et program for feilsøking og profilering av programvare for Linux. Cachegrind ble designet for å analysere statistikk over cacher, minnebruk og programkommandoer. Et annet Valgrind-verktøy, Callgrind, tegner anropsgrafer. Når det gjelder PHP, kan vi bruke denne applikasjonen til å visualisere og analysere profileringsloggen.
Verktøyet som vanligvis brukes til å analysere profileringsloggen generert av xdebug kalles . KCachegrind er gratis programvare lisensiert under GPL (fungerer bare på Unix-systemer). Det finnes imidlertid et enkelt program for Windows, som også er gratis. La oss først se på Windows-versjonen.
WinCacheGrind: analyse av profileringslogger i Windows
Den nåværende versjonen (i skrivende stund av forfatteren av denne artikkelen) av WinCachegrind er 1.0.0.12. Denne versjonen går tilbake til 2005, noe som betyr at WinCachegrind ikke har blitt utviklet på lenge. Hvis du ser på utgivelsesnotatene, skriver forfatterne at programmet har feil som noen ganger får det til å oppføre seg merkelig.
Derfor anbefaler jeg å bruke KCachegrind, lansert på grunnlag av en virtuell maskin på den nyeste Linux-distribusjonen, for eksempel Ubuntu (oversetterens notat, generelt sett, en merkelig anbefaling; i dette tilfellet vil jeg anbefale å bare installere Linux, og ikke gjerde inn hagen til virtuelle maskiner). Det er et stort antall virtuelle maskiner tilgjengelig under Windows. Hvis det av en eller annen grunn ikke er mulig å bruke Unix eller en virtuell maskin, kan du fortsette å bruke WinCachegrind for enkel profileringslogganalyse. WinCachegrind tegner ikke anropsgrafer, i motsetning til KCachegrind.
Det er ekstremt enkelt å installere Wincachegrind. Kjør installasjonsprogrammet, klikk på knappen for å godta lisensen og installasjonen er fullført. Nå kan du kjøre programmet og åpne en av cachegrind-profileringsloggene opprettet av xdebug.
Ved å klikke på klokken eller sigma-ikonet kan du bytte mellom å vise informasjon i absolutte verdier og prosenter. Prosentvisningen viser hvor mye tid, i prosent av den totale tiden, det tar å kalle en funksjon i en gitt blokk.
To nyttige innstillinger er Profiler -> Skjul raske funksjoner og Profiler -> Skjul bibliotekfunksjoner. Den første bryteren skjuler funksjoner hvis tidsbidrag til den totale programgjennomføringstiden er ubetydelig.
Den andre innstillingen, Profiler -> Hide Library Functions, skjuler funksjoner innebygd i PHP fra den generelle analysen. Når begge disse innstillingene er aktivert, ser du mindre data, slik at du kan fokusere på områder av koden din som trenger optimalisering.
Hovedvinduet inneholder to faner: Linje for linje og Samlet. Begge fanene viser den samme informasjonen, men Total-fanen samler informasjonen for en bedre presentasjon. Egentid viser kjøretiden til koden i gjeldende blokk, mens Kumulativ tid (Cum.) viser den totale kjøretiden til funksjonene i den gitte blokken.
KCacheGrind: analyse av profileringslogger i Unix
Unix-versjonen av KCachegrind gir mer funksjonalitet enn WinCachegrind. KCachegrind visualiserer dataene og bygger en samtalegraf.
For å begynne å bruke det, må du installere KCachegrind. Gjeldende versjon . En nyere versjon (0.10.1) er tilgjengelig, men den er en del av Valgrind-pakken.
Hvis mulig, bruk en pakkebehandling for å installere KCachegrind-pakken. KCachegrind bruker GraphViz til å tegne anropsgrafer, så du må også installere GraphViz-pakken hvis pakkebehandlingen ikke automatisk installerer avhengige pakker.
Hvis du ikke finner den binære KCachegrind-pakken, må du kompilere KCachegrind selv. Etter å ha lastet ned kildene, kjør
./configure --prefix=/opt/kde3
gjøre
gjøre installer
Som du kan merke, må du spesifisere banen til gjeldende installasjon av KDE-biblioteket. Hvis du ikke vet hvor KDE-bibliotekene er plassert på systemet ditt, bruk
for å vise banen til KDE-bibliotekene.
Når den er installert, kan du kjøre KCacheGrind fra kommandolinjen
Tabellvisning av data i KCachegrind er veldig lik WinCachegrind. Du kan også bytte mellom absolutte og prosentverdier. Noen KCachegrind-funksjoner er ikke laget for PHP. Bildet nedenfor viser samtalegrafen til phpMyAdmin-programmet:
Som du kan se, ble mesteparten av oppstartstiden brukt i common.inc.php. Følgende skjermbilde viser en visualisering av funksjonsanrop i common.inc.php:
Denne kodeblokken kjører to require_onces, som er halvparten av tiden det tar å kjøre common.inc.php. Dobbeltklikk på et hvilket som helst rektangel vil ta deg dypere inn i dataanalyse.
Kodeoptimalisering basert på profileringsdata
Profiler alltid applikasjonene dine før du optimaliserer. Du kan starte optimalisering selv, på stedet der det ser ut til at denne optimaliseringen vil gi effekt, men dette er ikke alltid sant. Optimalisering har hovedsakelig effekt kun i de delene som tar mest tid i utførelsesprosessen.
Hvis du kjører mange kopier av et program samtidig, kan det hende du fortsatt må optimalisere den delen av programmet som tar mesteparten av utførelsestiden. I dette tilfellet vil ikke optimaliseringen gjøre visningen av én individuell forespørsel raskere, men vil tillate serveren din å håndtere høye belastninger mens den bruker færre ressurser for å betjene disse forespørslene.
Når du ser på varigheten av profileringskjøring, husk at absolutte verdier er mindre viktige enn relative verdier. Målt på forskjellige systemer kan absolutte verdier variere. Men før du begynner å optimalisere koden, bør du vurdere følgende ting.
En viktig regel i optimalisering er å redusere antall I/O-operasjoner. Noen I/O-operasjoner er svært tidkrevende sammenlignet med beregninger. Å redusere slike operasjoner kan være en svært effektiv måte å få fart på programmet. Å fjerne ett I/O-anrop kan gi en mer effektiv forbedring enn å bruke mange timer på å optimalisere koden. Derfor bør du først fokusere på I/O-operasjoner før du begynner å kode.
Du kan også øke antallet servere før du optimaliserer. Du kan kjøpe en stor, som vil gi deg en liten økning i produktiviteten. Utviklingstiden er dyrere enn prisen på en ny server. Og hvis du øker mengden maskinvare, kan du være sikker på at du får økningen umiddelbart uten noen innvirkning på PHP-koden. Når en utvikler bruker én eller to dager på å optimalisere kode, kan du aldri si hvor mye produktiviteten vil øke. Og til slutt kan du ikke lenger være sikker på at optimalisering ikke vil gi noen feil.
Konvertering av noen sider til statiske sider er en måte å oppnå bedre ytelse på. La oss si at det er et nettsted med mye trafikk, der et PHP-skript lager den første siden for hver forespørsel, og velger informasjon fra en database eller XML-fil. Hvis dataene på en side endres ofte nok, kan du gjenskape en statisk kopi av den. Hvis konvertering til en statisk visning ikke er mulig for en side (noen personlig informasjon vises på siden), kan du konvertere noen blokker til statisk visning.
Et annet optimaliseringsnivå krever ikke endring av PHP-koden. Som vi vet er PHP et tolket språk. Dette betyr at kommandoene oversettes under kjøring til mellomkode. Sendingen gjentas hver gang manuset kjøres. Dette gjør PHP tregere sammenlignet med språk som C eller Java, som ikke krever å analysere koden hver gang du kjører den. For PHP kan du bruke mellomliggende representasjonscacher (se min oversettelse....) for å lagre og gjenbruke mellomkode, dette gjør oppstart og utførelse raskere.
Alt dette betyr ikke at dette ikke er tiden eller stedet for å optimalisere PHP-koden. Noen kodeoptimaliseringer kan forbedre ytelsen betraktelig. Husk imidlertid alltid at endring av kode alltid medfører risiko for å introdusere flere feil og sikkerhetsproblemer. Husk også at optimalisering av koden din gjør den mindre lesbar.
Konklusjon
Å lage og visualisere en profileringslogg er en av de viktige betingelsene for å optimalisere PHP-kode. Du må vite hvilke steder i programmet som tar mest tid, og det er der du bør begynne å optimalisere.
I den neste artikkelen skal vi se på feilsøking ved hjelp av xdebug. xdebug kan gi deg muligheten til å utføre ekstern feilsøking. Ved å bruke en klient som har denne muligheten, for eksempel Eclipse PDT, kan du feilsøke koden din uten å endre den, angi bruddpunkter, hoppe gjennom deler av koden og se hvordan og hvor variabler endrer verdier.
Applikasjonsprofilering er innsamling av data om utførelseshastigheten til ulike programseksjoner (filer og funksjoner). Det er mange PHP-profileringsverktøy tilgjengelig, men ikke alle verktøy er egnet for å utføre analyser direkte på et produksjonssted.
XHProf og dens gaffel Tideways er en praktisk og enkel profiler som effektivt kan samle inn statistikk om driften av en applikasjon med nesten ingen reduksjon i hastigheten til applikasjonen din (eller nettstedet ditt).
Hvorfor profilkode?
Hvis applikasjonen begynner å fungere sakte (les "nettstedet begynte å gå tregere"), vil profilering tillate deg å finne ut hvilken del som er tregest. Resultatet av profilering er vanligvis en liste over utførte funksjoner sammen med deres utførelsestid.
Kodeprofilering bør komme først issen. Noe annet ville være gjetting og mest sannsynlig feil. Du må vite nøyaktig hva som forårsaker problemer og "bremser".
Profilering er en prosedyre for å samle inn og organisere statistikk om utførelsestidspunkt for kode. Dette er ikke en prosess for optimalisering eller programmodifisering. Resultatet av denne prosessen er vanligvis en utvidet rapport om programkomponenter og funksjonsytelsestatistikk.
Det er nettopp dette XHProf-løsningen ble utviklet for. Den er designet for å fungere på ekte nettsteder. Hovedideen med denne profileren er å skape en minimumsbelastning på applikasjonen, mens du samler inn alle nødvendige data om operasjonshastigheten. Løsningen er utviklet av spesialister fra Facebook.
Hvordan koble til php profiler automatisk?
Våre spesialister har jobbet hardt og gjort denne prosessen fullstendig automatisert.
Du trenger bare å logge på, velg ønsket domene i "Domener"-fanen, klikk på "PHP.INI + PHP Profiler"-ikonet og aktiver "Domeneprofiler" avkrysningsboksen.
Det kan ta litt tid å aktivere denne funksjonen, vanligvis ikke mer enn 10 minutter.
For php versjoner 5.2, 5.3, 5.4, 5.5, 5.6, 7.0 bruker vi XHProf profiler, for php versjoner 7.1 og høyere bruker vi Tideways profiler.
Når den er aktivert, på hver side på nettstedet ditt som behandles av PHP, vil en spesiell blokk med lenker til rapportfilen bygges inn i bunnen av den (lenken vil se omtrent slik ut:
Domain-name.com/xhprof-master/xhprof_html/index.php?run=XXXXXXXXXXXX&source=someapp)
Og her er hvordan rapportfilen vil se ut:
Tabellen inneholder en liste over funksjoner som ble utført på én side med tilleggsinformasjon:
- Anrop - antall og prosentandel funksjonsanrop
- Inkl. Veggtid - utførelsestid for en funksjon med nestede funksjoner
- Ekskl. Veggtid - funksjonsutførelsestid uten nestede funksjoner
- Inkl. CPU - prosessortid med nestede funksjoner
- Ekskl. CPU - prosessortid uten nestede funksjoner
- Inkl. MemUse - minneforbruk med nestede funksjoner
- Ekskl. MemUse - minneforbruk uten nestede funksjoner
- Inkl. PeakMemUse - maksimalt minneforbruk med nestede funksjoner
- Ekskl. PeakMemUse - maksimalt minneforbruk uten nestede funksjoner
Det skal bemerkes at rapporten bygget ved hjelp av tidevann kan være litt visuelt forskjellig fra denne rapporten, men essensen endres ikke.
Grafiske rapporter
Ressursintensive deler av koden er uthevet i gult (middels) og rødt (tyngst). Dette er de delene av kode som bruker mye ressurser i forhold til resten av programmet. Dette kan være én sakte funksjon eller mange anrop til en rask funksjon. I vårt eksempel ser vi at mysqli_multi_query()-funksjonen er merket med rødt fordi den kjører tregest.
Samlede rapporter
XHProf-grensesnittet lar deg også se samlet informasjon fra flere rapporter samtidig. For å gjøre dette, sendes run_id atskilt med kommaer:
Domenenavn.com/xhprof-master/xhprof_html/index.php?run=XXXXXXXXXXXX,YYYYYYYYYYY&source=someapp
Tekniske funksjoner
- Å gå inn på en hvilken som helst side behandlet av php vil derfor utløse opprettelsen av en ny rapportfil, så vi anbefaler å deaktivere profileringsverktøyet etter å ha samlet inn statistikk (vanligvis tar dette flere timer), for å unngå å renne over diskkvoten, som kan være oppbrukt etter generering et stort antall rapporter!
- Viktig: Profiler vil bare fungere hvis siden er koblet til serveren via en standard bane, med automatiske midler (det vil si ved å bruke vertskontrollpanelet), ellers må du kontakte Hostland teknisk støtte for å konfigurere profileren.
- I automatisk modus kobler profiler kun til hoveddomenenavnet, profiler kobles ikke automatisk til underdomener.
- I automatisk modus samler profiler kun inn statistikk for skript med utvidelsen .php og .php5
- Det er ikke mulig å garantere uavbrutt drift av nettstedet etter tilkobling av PHP-profiler, derfor, hvis nettstedet ikke fungerer riktig mens profileringsprogrammet er aktivert, bør det deaktiveres og profilering fortsette på andre måter.
Automatisk inkludering av profiler implementeres ved å bruke auto_append_file og auto_prepend_file-direktivene, som kobler sammen to kjørbare php-filer:
— auto_append_file initialiserer statistikkinnsamlingsobjektet og starter arbeidet;
— auto_prepend_file fullfører innsamlingen av statistikk og genererer en rapportfil med statistikk (i JSON-format);
Hvis exit() eller die() kalles mens skriptet kjører, vil ikke auto_prepend_file bli utført. statistikkfilen vil ikke bli generert og en blokk med lenker til rapportfilen vil ikke bli inkludert nederst på siden.
La oss oppsummere det
Vi håper dette verktøyet vil hjelpe deg å gjøre sidene dine enda raskere på Hostland-hosting.
Artikkelen brukte delvis materiale fra brukeren Den Golotyuk lagt ut på nettstedet
FirePHP er en utvidelse for firebug, som sammen med sin lille php-klasse lar deg kringkaste data fra php, for eksempel all slags var_dump og annen feilsøkingsinformasjon, til firebug-konsollen. Den største fordelen med denne utvidelsen er at all feilsøkingsinformasjon kringkastes gjennom overskrifter og forsøpler ikke sidene og bryter ikke logikken til programmet på noen måte Offisiell nettside: http://firephp.org/.
Hovedide.
Den generelle profileringsalgoritmen er som følger:- På begynnelsen av siden aktiverer vi profilering ved å bruke xhprof_enable()
- På slutten av siden slår du av profilering med xhprof_disable() og lagrer de innsamlede dataene ved å bruke save_run()
- Deretter, ved å bruke firephp php-klassen, sender vi en lenke til profileringsdataene til klientdelen
- I firebug-konsollen åpner vi informasjonen vi trenger
- Vi gleder oss :)
I våre prosjekter, i nesten alle skript, er en arbeidsfil med en klasselaster, tilkoblingsfunksjoner og andre nødvendige ting koblet til i begynnelsen. Derfor inkluderte vi inkludering av profilering i denne filen. Og for å kunne slå på/av feilsøkingsmodusen etter ønske, la vi til en sjekk for konfigurasjonskonstanten, pluss at vi pakket inn disse sjekkene i noen metakoder som automatisk fjernes når prosjektet bygges. Det samme gjelder for å slå av profilering og skrive informasjon til overskrifter ved hjelp av firephp – disse oppgavene løses av én funksjon, som kalles på slutten av hvert PHP-skript og også er pakket inn i metakoder. Det ser omtrent slik ut:
// Følgende konstanter er skrevet i applikasjonens konfigurasjonsfil/** Driftsmåte for miljøet * */
define("APPLICATION_ENV" , "dev" ); // dev - feilsøking | pro - produksjon
/** Bane til profiler */
define("XHPROF_ROOT" , __DIR__ . "/ExtProcs/debug/xhprof-0.9.2");/***************************************************************************************
* Deretter starter vi profilering i filen som er lastet inn i begynnelsen av hvert skript
* DEV_START og DEV_END er metakodene våre, alt mellom dem kuttes ut under montering
***************************************************************************************///-- DEV_START
//-- i feilsøkingsmodus kobler vi til feilsøkingsbiblioteker
// Last inn firephp
require_once(__DIR__ . "/includes/ExtProcs/debug/firephp/FirePHP.class.php");
//-- last profiler
"/xhprof_lib/utils/xhprof_lib.php");
require_once(XHPROF_ROOT. "/xhprof_lib/utils/xhprof_runs.php");
// Initialiser profilering med de nødvendige flaggene. Detaljert beskrivelse av flagg
// kan finnes på php.net/manual/ru/xhprof.constants.php
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
}
//-- DEV_END// Vel, denne funksjonen kalles på slutten av hvert skript
// Samtalen er også pakket inn i DEV_START og DEV_END/**
* Lag en lenke til profileringsresultatet og vis det i konsollen
*/
funksjon dev_boot_Down() (
if (APPLICATION_ENV === "dev" ) (
// Initialiser firephp-forekomsten
$firephp = FirePHP::getInstance(true);
// Slå av profilering og lagre data
$xhprof_data = xhprof_disable();
$xhprof_runs = ny XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_testing" );
// Lag en lenke til profileringsdataene og skriv den til konsollen
$link = "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, "profileringsdata" );
}
}
* Denne kildekoden ble uthevet med Source Code Highlighter.
Jeg vil ikke gå inn på detaljer om å installere disse utvidelsene, fordi alt er enkelt her. Jeg vil bare si om noen aspekter ved oppsettet. xhproof har bare én konfigurasjonsvariabel - xhprof.output_dir, som peker til mappen der profileringsdata vil bli lagret. Sørg derfor for at brukeren som PHP-skriptene kjøres under har skriverettigheter til den angitte katalogen. Så skriv noe slikt i php.ini:
extension=xhprof.so
xhprof.output_dir="/var/tmp/xhprof"
Det er også en god idé å installere noe som dot eller Graphviz for å tegne samtalegrafer. Jeg har Graphviz på MacOS X.
Etter å ha fullført prosedyrene beskrevet ovenfor, var vi i stand til å åpne og se på profileringen av alle skriptene våre direkte i nettleseren når som helst.
Over tid står enhver PHP-programmerer overfor problemet med dårlig ytelse til applikasjonen hans. Det kan være at en bestemt side lastes sakte eller at svaret fra API-en tar for lang tid. Og noen ganger er det ganske vanskelig å forstå hva som er årsaken til bremsene? Noen ganger oppstår mer komplekse situasjoner: på produksjonsserveren er API'et veldig tregt, men på benken der utviklingen foregår er alt bra. Og finn ut hva som går galt. Feilsøking på en produksjonsserver er en ekstrem grad av håpløshet, som det selvfølgelig er bedre å ikke lede til.
Det er for slike situasjoner at spesielle verktøy kalt applikasjonsprofiler ble oppfunnet. I PHP-verdenen spilles denne rollen av xDebug, så vel som xhprof. xhprof er et lettere, enklere og mer fleksibelt verktøy, så bruken er å foretrekke. Interessant nok ble xhprof utviklet av facebook tilbake i 2009, men det er fortsatt ingen offisiell støtte for php7 fra dem, og det vil ikke være mer siden facebook har byttet til HHVM. Men takket være det omfattende fellesskapet av PHP-utviklere, har det dukket opp en gaffel som støtter PHP7, hvis installasjon ikke forårsaker noen vanskeligheter.
InstallasjonFørst må du faktisk installere xhprof:
Git clone 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"
/var/tmp/xhprof-mappen må ha skrivetilgang, fordi profileringsresultater vil bli lagret der.
Du kan laste PHP-FPM på nytt og sjekke om utvidelsen er installert. Det er banalt, dette kan gjøres ved å bruke utdata fra phpinfo()-funksjonen;
xhprof er installert, kan du bruke den. xhprof-pakken inkluderer et svært brukervennlig grensesnitt for å analysere profileringsrapporter. xhprof lar deg bygge rapporter, både i tekst og grafisk form. Installasjonsmappen xhprof inneholder xhprof_html og xhprof_lib, som vi trenger. Mappe xhprof_html - gir tilgang til GUI. xhprof_lib - bibliotek for visning og analyse av kode. Det er tilrådelig å flytte hele xhprof-mappen til /var/www/xhprof og konfigurere en virtuell vert for den, for eksempel xhprof.loc. Eksempel for nginx:
Server ( lytt 80; server_name xhprof.loc; charset utf-8; root /var/www/xhprof/xhprof_html; index index.php; plassering / ( try_files $uri $uri/ /index.php?q=$uri&$args ; ) plassering ~ \.php ( fastcgi_pass 127.0.0.1:9000; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; inkluderer fastcgi)_params; )
Du må også huske å oppdatere vertsfilen. Nå, når vi skriver inn URL-en xhprof.loc i nettleseren, vil vi bli ført til profilerens nettgrensesnitt, hvor filene som genereres av den vil være tilgjengelige.
Nå kan du gå direkte videre til profilering av koden.
For å aktivere profiler, bruk xhprof_enable()-funksjonen, som godtar følgende flagg som input:
- XHPROF_FLAGS_CPU - for opptak av prosessorstatistikk;
- XHPROF_FLAGS_MEMORY - for minne;
- XHPROF_FLAGS_NO_BUILTINS - for å ignorere innebygde funksjoner.
For å deaktivere profiler, bruk xhprof_disable()-funksjonen. For enkelhets skyld vil vi skrive to skript header.php og footer.php som utfører disse funksjonene. header.php er inkludert i begynnelsen av det profilerte skriptet, og footer.php - på slutten. footer.php er også ansvarlig for lagring av 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/xhprof_runs.php"; xhprof_enable(XHPROF_FLAGS_CPU); ) footer.php: if (extension_loaded("xhprof")) ( $profilerNamespace = "NAVN PÅ PROFILERT SKRIPT HER"; $xhprofData = xhprof_disable(); $xhprofRuns = new $_IProfuns $); xhpro fRuns->save_run ($xhprofData, $profilerNamespace); )Bruk
Etter å ha koblet header.php og footer.php til det profilerte skriptet, kan du begynne: når du kjører det profilerte skriptet, vil en fil bli generert som vil bli lagret i /var/tmp/xhprof-katalogen, som inneholder informasjon om driften av manus. Når du åpner webgrensesnittet xhprof.loc, vil denne genererte filen være tilgjengelig:
Når du åpner en profileringsfil, vises detaljert informasjon om driften av applikasjonen, hele anropsstakken:
Hva betyr kolonnene:
- Samtaler- antall og prosentandel av funksjonsanrop;
- Inkl. Veggtid- utførelsestid for en funksjon med nestede funksjoner;
- Ekskl. Veggtid- utførelsestid for en funksjon uten nestede funksjoner;
- Inkl. prosessor- CPU-tid med nestede funksjoner;
- Ekskl. prosessor- CPU-tid uten nestede funksjoner;
- Inkl. MemUse- minneforbruk med nestede funksjoner;
- Ekskl. MemUse- minneforbruk uten nestede funksjoner;
- Inkl. PeakMemUse- maksimalt minneforbruk med nestede funksjoner;
- Ekskl. PeakMemUse- maksimalt minneforbruk uten nestede funksjoner.
Hvis du følger lenken, vil et vakkert anropstre vises med en visuell indikasjon på den mest trege koden. Hvis dette ikke skjer, må du sannsynligvis installere graphviz-biblioteket:
Apt-get install graphviz
Et eksempel på en konstruert graf:
I mitt tilfelle er flaskehalsen interaksjon med databasen.
Bruke xhprof på en produksjonsserver
Opprinnelig ble xhprof utviklet spesielt med det formål å profilere kode i kamp, på produksjonsservere. Det finnes rett og slett ikke noe annet gratis og effektivt verktøy for å profilere PHP7-kode i kamp, så xhprof har ingen konkurrenter. Nærmere bestemt har jeg erfaring med å bruke xhprof på en produksjonsserver som behandler en million forespørsler per dag. Den bruker php7 og ingen problemer har blitt funnet så langt. Imidlertid kjøres ikke xhprof for hver forespørsel - det vil generere for mange profileringsfiler. For meg starter profileringen bare hvis forespørselen har "XHPROF_ENABLE"-overskriften og den er satt til sann. Du kan også bruke en annen strategi, for eksempel kjøre profileren tilfeldig med en sannsynlighet på for eksempel 1/1000. Da blir det også et ganske klart bilde.
Konklusjon
Selv om xhprof ikke offisielt støttes for php7, er det fortsatt et uunnværlig verktøy for en php-utvikler.
Applikasjonsprofilering er innsamling av data om utførelseshastigheten til ulike programseksjoner (filer og funksjoner). Det er mange PHP-profileringsverktøy tilgjengelig, men ikke alle verktøy er egnet for å utføre analyser direkte i produksjonen.
XHProf- en mega enkel profiler som samler inn statistikk direkte mens applikasjonen kjører nesten uten overhead.
Hvorfor profil?
Hvis en applikasjon begynner å kjøre sakte, kan profilering hjelpe deg med å finne ut hvilken del som er treg. Resultatet av profilering er vanligvis en liste over utførte funksjoner og deres utførelsestid.
Profilering bør gjøres før enhver applikasjonsoptimalisering. Ellers vil du bli veiledet av gjetting. Mest sannsynlig feil. 
Xdebug-problem
Xdebug er en kraftig løsning for PHP. Men selve Xdebug-plattformen er så tung at den kan ikke brukes på live nettsteder. XDebug skaper en betydelig belastning på serverressurser og senker applikasjonen. 
På den annen side kan problemer på en live-side være helt forskjellige fra de i et utviklingsmiljø. Profilering kun på utviklerdatamaskiner vil vise bare en del av problemene.
Derfor ble løsningen utviklet XHprof. Den er beregnet for bruk i applikasjoner som kjører. Hovedideen til denne profileren er å skape en minimumsbelastning på applikasjonen mens du samler inn alle nødvendige data om operasjonshastigheten. Løsningen er utviklet av gutta fra Facebook og støttes av nye versjoner av PHP.
XHProf
Installasjon
På Debian er XHprof i sid-pakker, så: apt-get install xhprof
Du kan også bygge XHprof selv.
Aktiver profilering
La oss si at vi har et skript med følgende kode:
henrette();
La oss utføre profilering med XHprof. For å gjøre dette på denne siden trenger du:
- Aktiver profileringsverktøyet helt i begynnelsen.
- Helt på slutten av programmet stopper du profileringen og lagrer de mottatte dataene.
Det vil se slik ut:
# Initialiser profilerenxhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY); # Kjør programmet etter at du har slått på profileren henrette(); # Stopp profileringsverktøyet etter å ha kjørt programmet$xhprof_data = xhprof_disable();
# Lagre profileringsresultatet til $xhprof_data-variabelen
- Funksjon xhprof_enable() tar flagg som argumenter. XHPROF_FLAGS_CPU for registrering av prosessorstatistikk, XHPROF_FLAGS_MEMORY for minne, XHPROF_FLAGS_NO_BUILTINS for å ignorere innebygde funksjoner.
- xhprof_disable() vil slå av profileringsverktøyet og returnere den innsamlede statistikken.
Rapporter
Generasjon
De innsamlede dataene kan analyseres i XHprof-grensesnittet for å generere rapporter. For å gjøre dette, må du laste ned XHprof-kildene: cd /var/www; wget http://pecl.php.net/get/xhprof-0.9.4.tgz gzip -d xhprof-0.9.4.tgz tar -xvf xhprof-0.9.4.tar
Etter dette må du gjøre endringer i skriptet:
include_once "/var/www/xhprof-0.9.4/xhprof_lib/utils/xhprof_lib.php"; include_once "/var/www/xhprof-0.9.4/xhprof_lib/utils/xhprof_runs.php"; $xhprof_runs = ny XHProfRuns_Default(); $run_id = $xhprof_runs->save_run($xhprof_data, "test");
# Ny kode lagrer rapporten for bruk i GUI
Grensesnitt for rapporter
For å se rapporten må du konfigurere den virtuelle verten til mappen /var/www/xhprof-0.9.4/xhprof_html. For eksempel, i Nginx:
Server ( server_name xh..9.4/xhprof_html; index index.php; plassering ~* \.(php)$ ( fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILNAVN $fastcgi_x) -s reload
Etter dette vil en liste over rapporter vises:
Tabellen inneholder en liste over funksjoner som ble utført på én side med tilleggsinformasjon:
- Anrop — antall og prosentandel av funksjonsanrop.
- Inkl. Veggtid — utførelsestid for en funksjon med nestede funksjoner.
- Ekskl. Veggtid er utførelsestiden for en funksjon uten nestede funksjoner.
- Inkl. CPU - prosessortid med nestede funksjoner.
- Ekskl. CPU - prosessortid uten nestede funksjoner.
- Inkl. MemUse - minneforbruk med nestede funksjoner.
- Ekskl. MemUse - minneforbruk uten nestede funksjoner.
- Inkl. PeakMemUse - maksimalt minneforbruk med nestede funksjoner.
- Ekskl. PeakMemUse - maksimalt minneforbruk uten nestede funksjoner.
Grafiske rapporter
For å bygge en grafisk rapport, sørg for at du har graphviz installert: apt-get install graphviz
Ressursintensive deler av koden er uthevet i gult (middels) og rødt (tyngst). Dette er de delene av kode som bruker mye ressurser i forhold til resten av programmet. Dette kan være én sakte funksjon eller mange anrop til en rask funksjon. I vårt eksempel er funksjonen str_replace() merket rødt på grunn av 262 anrop.
Samlede rapporter
XHprof-grensesnittet lar deg også se samlet informasjon fra flere rapporter samtidig. For å gjøre dette sendes run_id atskilt med kommaer: http://xh..php?run= 53a894f6d5d9b,53a894fcf126e&kilde=test
TL;DR
Bruk XHprof til å profilere PHP direkte i produksjon.
Laster inn...
