Phpstorm e Xdebug + Profiling

Con Xdebug 3 le direttive remote_enable e profiler_enable dei vecchi esempi non sono più la configurazione corretta. Installa l’estensione compatibile con PHP e verifica che sia caricata nella SAPI usata. Non copiare il vecchio percorso assoluto di xdebug.so.

xdebug.mode=debug,profile
xdebug.start_with_request=trigger
xdebug.client_host=127.0.0.1
xdebug.client_port=9003
xdebug.output_dir=/percorso/privato/xdebug
xdebug.profiler_output_name=cachegrind.out.%p.%t

La directory deve esistere ed essere scrivibile dall’utente PHP, ma non esposta dal web server. Nell’esempio IDE e PHP sono sulla stessa macchina; per Docker o un host remoto cambia client_host e configura i mapping in PhpStorm. Riavvia PHP-FPM, se lo usi, dopo aver modificato il suo INI.

Attivazione mirata

In sviluppo abilita l’ascolto in PhpStorm e passa XDEBUG_TRIGGER=1 tramite variabile d’ambiente per CLI o parametro della richiesta web. Con entrambi i modi abilitati, il trigger può attivare sia debug sia profiling. Per misurazioni meno influenzate dal debugger usa solo profile. Apri il file Cachegrind prodotto con l’analizzatore di PhpStorm o KCachegrind e controlla chiamate e tempi inclusivi.

Profilare ogni richiesta aumenta carico e occupazione disco. Mantieni l’attivazione su richiesta e ripulisci i file privati. Gli screenshot seguenti documentano l’interfaccia storica di PhpStorm, non la disposizione dei comandi attuale.

Una prova ripetibile

Per isolare il test dal web server, salva come profilo.php il codice seguente:

<?php
function lavoro(): void { usleep(50000); }
lavoro();
echo "Fine", PHP_EOL;

XDEBUG_MODE=profile XDEBUG_TRIGGER=1 php profilo.php

Devi ottenere Fine e un nuovo file cachegrind.out nella directory configurata, eventualmente compresso. Aprilo con Tools → Analyze Xdebug Profiler Snapshot in PhpStorm: lavoro deve comparire nelle chiamate e includere l’attesa. Se il file manca, controlla php --ri xdebug, directory scrivibile e trigger. Questo test usa solo profile e non richiede un breakpoint.