7/6/2023 0 Comments Xdebug phpstorm windowsIf you want to try this out in a real-world project, and are not familiar enough with Docker to do so quickly, then you can clone my new FOSS Dashtainer repo and run the bin/init script to get you up and running in a single step. If you use file-based sessions (why?) then you’ll have to share the volumes between the PHP containers. I have not found any downsides to this technique. On containers it is easier, simpler and faster. This solution would have been much heavier on virtual machines. However, since completely making the switch to Docker containers, my workflow has changed for the better, even with the slowness Docker for Mac shows.ĭocker containers have the benefit of being incredibly light-weight compared to virtual machines, and this makes spinning up two PHP containers for each of my projects completely feasible. My FOSS PuPHPet is evidence that I was all-in on VMs. Until 6 months ago I was using Vagrant virtual machines for all my development. The biggest (and only) painpoint that Xdebug introduces is completely eliminated. When this happens, I have a breakpoint enabled and will be looking at my IDE, so response times do not matter at all. When I do want to enable debugging, I set my breakpoint, enable the XDEBUG_SESSION cookie by using PhpStorm’s bookmarklets, and Nginx routes my request to the PHP server with Xdebug installed. This is still not great (because, Docker), but is worlds better than every single request being 1,000ms+! On my MacBook Pro requests see a normal response time of sub-500ms. It does not change!īut, instead of Xdebug slowing down every single request, whether you have set a breakpoint or not, whenever you do not have the XDEBUG_SESSION cookie enabled, you are hitting the non-Xdebug server! In real-world testing this means that the majority of my requests are now routed directly to the PHP server that does not have Xdebug installed. With my Nginx map solution, your workflow remains exactly the same. You load the page in your browser, Xdebug and your IDE connect and stop at the breakpoint defined.You create a breakpoint and enable the listener in your IDE.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.
0 Comments
Leave a Reply. |