You enable the Xdebug cookie in your browser.

Your normal workflow with Xdebug would look like this: The other server would remain blissfully unaware of the request. There is nothing magical about this, and PHP is not aware that a request is being made until Nginx has made the decision to route the request to its server. Nginx reads the cookie and sends traffic either to the php server or the php_xdebug server.

You can see how we’re actually using the result of the map at fastcgi_pass $my_fastcgi_pass:9000. If you take a look at PhpStorm’s bookmarklets, the code is actually quite simple: The all also let the PHP layer of your application decide whether to enable Xdebug for the current session.

You can also kick Xdebug off via CLI to debug command line scripts without a web portion.Īll methods share the same requirement: Xdebug must be installed and loaded on the system to work. The more popular ways are using cookies, like those generated by PhpStorms bookmarklets.

There are several ways of enabling Xdebug for a specific session.

I have been using Xdebug for several years and while I always felt the benefits of Xdebug far out-weighed the extra slowness, I knew there had to be a better way. If Xdebug is activated response times of 1,200ms+ can frustrate even the most devoted Xdebug fan.īefore switching to Fedora I tried everything I could to minimize Xdebug’s impact on performance. Not everyone has the luxury of switching their OS, though, and they are stuck on slow Docker.Ī normal Symfony 2.4 application will commonly see between 400ms-750ms response times in development mode, without Xdebug installed. It is so slow that I purchased a new Dell XPS laptop and for the first time in 6 years am now using a non-MacOS (Fedora) machine as my daily driver. Ed: If you want to jump right to the solution, jump ahead to Nginx map.

Docker on mac very slow