Xdebug ontwikkeling sneller maken

Als je de ontwikkelingssnelheid wilt verdubbelen tijdens het gebruik van Xdebug, dan leer je 't hier.

Het gebruik van Xdebug is zeer handig bij de ontwikkeling. Al onze lokale PHP containers hebben deze module dan ook standaard aan staan.
Het grote nadeel is dat dit zeer resource-heavy is en de laadtijd van je pagina dus ook redelijk vertraagt, zelfs als je de debugger niet hebt ingeschakeld in PHPStorm, wat toch het merendeel van de tijd is.

In een ideaal scenario laden we de Xdebug module enkel wanneer we deze nodig hebben, en dus niet voor alle andere requests naar de applicatie.

Een oplossing hiervoor bestaat erin om 2 PHP containers te gebruiken. 1 mét en 1 zonder de Xdebug module ingeschakeld. Zo kunnen we gebruik maken van de 'snellere' php container als we Xdebug niet nodig hebben en schakelen we over op de PHP Xdebug container als we effectief willen debuggen.

Door gebruik te maken van een cookie kunnen we via NGINX aangeven welke PHP container we wensen te gebruiken.

We maken naast onze standaard PHP container met naam php een nieuwe container aan met de naam php-dev. Beide containers laden verschillende Docker images in, namelijk:

• php container maakt gebruik van een PHP Docker image zonder Xdebug
• php-dev container gebruikt een PHP Docker image mét de Xdebug module ingeschakeld

Voorbeeld

1
2
3
4
5
services:
  php:
    image: some.docker.hub/php:7.3-fpm
  php-dev:
    image: some.docker.hub/php:7.3-fpm-dev

De magic vindt plaats in NGINX. In onze configuratie luisteren we naar het al dan niet geplaatst zijn van een cookie.
Indien dit het geval is, dan kunnen we onze php-dev container aanspreken, zoniet sturen we de request naar onze default php container zonder Xdebug.

Volgende snippet plaats je bovenaan in je nginx configuratiefile. Dit zet een $domainService variabele met als standaardwaarde php, dit is meteen ook de hostname van onze PHP container. Van zodra een cookie met waarde XDEBUG_ wordt aangetroffen, zal $domainService de waarde php-dev krijgen, de hostname van onze Xdebug PHP container.

1
2
3
4
map $http_cookie $domainService {
  default php;
  "~*XDEBUG_" php-dev;
}

In onze vorige configuraties gaven we een standaard adres mee voor onze FastCGI server, namelijk php (de hostname van onze container).

1
fastcgi_pass php:9000;

In de nieuwe situatie veranderen we dit door onze $domainService variabele.

1
fastcgi_pass $domainService:9000;

Mocht je om een bepaalde reden een applicatie hebben die gebruik maakt van Apache (requirements, Shibboleth, ...) is deze oplossing ook een mogelijkheid.

Binnen je <VirtualHost> tag voeg je het volgende toe

1
2
3
4
5
6
7
8
9
<FilesMatch \.php$>
    # Redirect to php-dev container with Xdebug loaded
    <If "%{HTTP_COOKIE} =~ /XDEBUG_/">
        SetHandler proxy:fcgi://php-dev:9000
    </If>
    <Else>
        SetHandler proxy:fcgi://php:9000
    </Else>
</FilesMatch>

Als je wisselt in je browser tussen debuggen en niet-debuggen zal je nu ook steeds een andere sessie krijgen, aangezien er een andere container wordt aangesproken.

Indien je dus iets moet debuggen achter authentication, dien je eerst de xdebug helper in te schakelen in de browser. Nu heb je een nieuwe sessie waarin je je kan aanmelden.

Door gebruik te maken van deze implementatie laden onze pagina's meer dan dubbel zo snel in als we niet aan het debuggen zijn, wat voor een aanzienlijke tijdswinst zorgt. We hebben zo het beste van beide werelden, Xdebug als het nodig is en snelle responsetijden tijdens ontwikkeling.

Nood aan PHP experts? Wij zijn de PHP experts van België.