Come valutare l'efficienza dello script PHP

Voglio sapere qual è il modo migliore per confrontare i miei script PHP. Non importa se un lavoro cron, una pagina Web o un servizio Web.

So di poter usare microtime ma mi sta davvero dando il tempo reale di uno script PHP?

Voglio testare e confrontare diverse funzioni in PHP che fanno la stessa cosa. Ad esempio, preg_matchvs strposo domdocumentvs preg_matcho preg_replace vs str_replace`

Esempio di una pagina Web:

<?php
// login.php

$start_time = microtime(TRUE);

session_start(); 
// do all my logic etc...

$end_time = microtime(TRUE);

echo $end_time - $start_time;

Questo produrrà: 0.0146126717 (varia continuamente - ma quello è l'ultimo che ho ricevuto). Ciò significa che ci sono voluti circa 0,015 per eseguire lo script PHP.

C'è un modo migliore?

Se vuoi davvero confrontare il codice del mondo reale, usa strumenti come Xdebug e XHProf .

Xdebug è ottimo per quando lavori in sviluppo / messa in scena e XHProf è un ottimo strumento per la produzione ed è sicuro eseguirlo lì (fintanto che leggi le istruzioni). I risultati di un singolo caricamento di pagina non saranno così rilevanti come vedere come il tuo codice funziona mentre il server viene martellato per fare anche un milione di altre cose e le risorse scarseggiano. Ciò solleva un'altra domanda: stai colmando il collo di bottiglia sulla CPU? RAM? I / O?

Devi anche guardare oltre il codice che stai eseguendo nei tuoi script per vedere come vengono serviti i tuoi script / pagine. Quale web server stai usando? Ad esempio, posso fare in modo che nginx + PHP-FPM esegua seriamente mod_php + Apache, che a sua volta viene troncato per servire contenuto statico usando un buon CDN.

La prossima cosa da considerare è ciò che stai cercando di ottimizzare?

• La velocità con cui la pagina viene visualizzata nel browser degli utenti è la priorità numero uno?
• L'obiettivo è far retrocedere ogni richiesta al server il più rapidamente possibile con il minimo consumo di CPU?

Il primo può essere aiutato facendo cose come comprimere tutte le risorse inviate al browser, ma ciò potrebbe (in alcune circostanze) allontanarti ulteriormente dal raggiungimento del secondo.

Speriamo che tutto quanto sopra possa aiutare a dimostrare che i test di "laboratorio" accuratamente isolati non rifletteranno le variabili e i problemi che incontrerai nella produzione e che devi identificare qual è il tuo obiettivo di alto livello e quindi cosa puoi fare per arrivarci, prima di scendere lungo la via dell'ottimizzazione micro / prematura all'inferno .

Per valutare la velocità con cui lo script completo viene eseguito sul server, esistono molti strumenti che è possibile utilizzare. Prima di tutto assicurati che il tuo script (preg_match vs strpos ad esempio) debba produrre gli stessi risultati per qualificare il tuo test.

Puoi usare:

• JMeter
• Strumento ApacheBench ( vedi un esempio )
• dbench
• http_load
• arricciatura-loader
• httperf
• assedio
• vegeta
• anche il codice che usi è buono ma con un ciclo più grande (come 1.000.000)

Ti consigliamo di guardare Xdebug e, più specificamente, le funzionalità di profilazione di Xdebug .

Fondamentalmente, abiliti il ​​profiler e ogni volta che carichi una pagina web crea un file cachegrind che può essere letto con WinCacheGrind o KCacheGrind .

Xdebug può essere un po 'complicato da configurare, quindi ecco la sezione pertinente del mio php.iniper riferimento:

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

Ed ecco uno screenshot di un .outfile in WinCacheGrind :

Ciò dovrebbe fornire ampi dettagli sull'efficacia del tuo script PHP. Vuoi scegliere come target le cose che richiedono più tempo. Ad esempio, potresti ottimizzare una funzione per impiegare metà del tempo, ma i tuoi sforzi sarebbero meglio serviti ottimizzando una funzione chiamata dozzine se non centinaia di volte durante il caricamento della pagina.

Se sei curioso, questa è solo una vecchia versione di un CMS che ho scritto per uso personale.

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

Permette di definire passaggi nel codice e riporta i tempi, l'utilizzo della memoria, il caricamento del server ecc. Tra due passaggi.

Qualcosa di simile a:

    $appgati->Step('1');

    // Do some code ...

    $appgati->Step('2');

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

Matrice di output di esempio:

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

Guarderei in xhprof . Non importa se viene eseguito sul cli o tramite un altro sapi (come fpm o fcgi o anche il modulo Apache).

La parte migliore di xhprof è che è anche abbastanza adatta per essere eseguita in produzione. Qualcosa che non funziona altrettanto bene con xdebug (l'ultima volta che ho controllato). xdebug ha un impatto sulle prestazioni e xhprof (non direi che non ce n'è nessuno) riesce molto meglio.

Usiamo spesso xhprof per raccogliere campioni con traffico reale e quindi analizzare il codice da lì.

In realtà non è un punto di riferimento in termini di tempo e tutto ciò, anche se lo fa anche. Rende molto semplice analizzare il traffico di produzione e quindi eseguire il drill-down al livello della funzione php nel callgraph raccolto.

Una volta compilata e caricata l'estensione, si inizia a profilare nel codice con:

xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

Fermare:

$xhprof_data = xhprof_disable();

Quindi salva i dati in un file o in un database, qualunque sia il galleggiante del tuo boath e non interrompe il normale runtime. Lo spingiamo in modo asincrono su S3 per centralizzare i dati (per poter vedere tutte le esecuzioni da tutti i nostri server).

Il codice su github contiene una cartella xhprof_html che scarichi sul server e con una configurazione minima, puoi visualizzare i dati raccolti e iniziare il drill down.

HTH!

Mettilo in un forciclo per fare ogni cosa 1.000.000 di volte per ottenere un numero più realistico. E avvia il timer solo prima del codice che desideri effettivamente confrontare, quindi registra l'ora di fine subito dopo (ovvero non avvia il timer prima del session_start().

Assicurati anche che il codice sia identico per ogni funzione che desideri confrontare, ad eccezione della funzione che stai impostando.

Il modo in cui viene eseguito lo script (cronjob, php dalla riga di comando, Apache, ecc.) Non dovrebbe fare la differenza poiché stai solo calcolando la differenza relativa tra la velocità delle diverse funzioni. Quindi questo rapporto dovrebbe rimanere lo stesso.

Se il computer su cui stai eseguendo il benchmark ha molte altre cose in corso, ciò potrebbe influire sui risultati del benchmark se si verifica un picco nell'utilizzo della CPU o della memoria da un'altra applicazione mentre il benchmark è in esecuzione. Ma finché hai molte risorse da risparmiare sul computer, non penso che questo sarà un problema.

Un buon inizio sta usando il profiler di xdebugs http://xdebug.org/docs/profiler

Forse non è la cosa più semplice da configurare e utilizzare, ma una volta che lo fai, i volumi di dati e la facilità di visualizzazione sono insostituibili.

Eric,

Ti stai ponendo la domanda sbagliata. Se il tuo script viene eseguito in ~ 15 mSec, il suo tempo è in gran parte irrilevante. Se si esegue un servizio condiviso, l'attivazione dell'immagine PHP richiederà ~ 100 mSec, leggendo nei file di script ~ 30-50 mSec se completamente memorizzata nella cache sul server, possibilmente 1 o più secondi se caricata da una farm NAS back-end. I ritardi di rete nel caricamento dei mobili della pagina possono aggiungere molti secondi.

Il problema principale qui è la percezione da parte degli utenti del tempo di caricamento: quanto tempo deve attendere tra il clic sul collegamento e la visualizzazione di una pagina completamente renderizzata. Dai un'occhiata a Google Page Speed che puoi utilizzare come estensione Ff o Chrome e alla documentazione di Pagespeed che discute in profondità su come ottenere buone prestazioni della pagina. Segui queste linee guida e cerca di ottenere punteggi di pagina migliori di 90/100. (La home page di Google ha un punteggio di 99/100 come il mio blog). Questo è il modo migliore per ottenere buone prestazioni percepite dall'utente.

È anche bene tenere d'occhio il tuo codice PHP e fare un controllo incrociato con questo link , al fine di assicurarti che la codifica stessa non disturbi potenzialmente le prestazioni dell'app.