How to profile your PHP applications with Xdebug | Hacker News Reader

How to profile your PHP applications with Xdebug

vincentbroute.fr

61 pointsmooreds26 comments

In my experience, Xdebug is not suited to the task. It has a big impact on the executed process, so profiling is slow and biased. The results need some extra processing to get interpreted, which is a pain when experimenting with code changes. It's been a long time since I last used Xdebug to profile anything, so maybe the situation is better now.

My preferred tool is php-spx. Once the extension is loaded into PHP, within seconds you get a flamegraph of where time is spent. It's also easy to apply to command-line scripts. And it's versatile enough (with the right settings) to profile long-running or memory heavy scripts. https://github.com/NoiseByNorthwest/php-spx

SPX could be loaded with docker-compose like this article does for Xdebug. But if you already have a PHP environment, the easiest way to install it is to compile it (sudo apt install php-dev && make && cp modules/spx.so /usr/lib/php/....).

My god that looks like a god send!

I've tried using xdebug for profiling, but as you say it is just not up to the task. Even leaving the extension enabled without any tracing or debug session enabled wreaks havoc on the performance characteristics.

XDebug is good for debugging code in development environments. Not for profiling in production.

Wow. This looks incredible. We're using Xdebug now and while we have no real complaints, this is on another level. Most of our machines are Linux based so we should be good, but we do have Windows hosts too in testing (unfortunate that it doesn't support them).

Funny timing — I just spent 4 hours this morning comparing Xdebug, Blackfire, and New Relic.

After feeling like my SaaS application is starting to hit some scaling bottlenecks, I had a play with all 3 services to try and get some performance insights for a real-world application.

A brief summary:

1. Xdebug: Slow. Fiddly to set up. Fine for a development environment when you need to dig into low-level profiling, but not suitable for production, where bottlenecks can be quite different.

Developer-friendly tools like Clockwork[0] are, practically speaking, far more insightful for identifying most bottlenecks in dev environments.

2. Blackfire: Terrible UX. Difficult setup process. Their free plan is almost impossible to evaluate as it only shows you glorified stack traces, most of which are littered with vendor and framework files. Their live demo of the complete package is poor too. I didn’t want to commit to paying a full year of their standard plan (no monthly payment option, unless you go for the highest tiers), so I happily uninstalled and moved on.

3. New Relic: wow… one command and a server reboot later, and I’m seeing performance profiling, consolidated dashboards, error logging, FPM and CLI throughput and traces, MariaDB and Redis queries, frontend performance, and server metrics - with REAL data, on production! I’m very, very impressed. And it’s free for a single user…?!

[0] Clockwork: https://underground.works/clockwork/

+1 for the helpful comparisons! I’ll definitely be checking out New Relic on Monday, sounds exactly what I’ve been looking for.

> Blackfire - Terrible UX

NewRelic is obviously fantastic, but it doesn't have the deep PHP-specific info provided by Blackfire.

https://tideways.com/ however does and is a _fantastic_ alternative to NewRelic for PHP codebases. I've no link to it other than as a satisfied customer.

It's saved me loads of time, usually in crisis moments when there's no time to spend on debugging the production service because things have to work again.

I concur on 1. I feel like this could be extended to every debug tool I’ve worked with, sadly. It’s hard to beat console.log (and associated methods) in JS or error_log and tail -f in PHP. The debugging tools always seem to add just enough overhead to not be worth the trouble in most cases. Yet there’s always someone writing a new article about how anyone who’s not using one is stuck in the dark ages for the clicks.

Might want to look at syslog() vs calls to error_log().

That's not really a fair comparison, xDebug is a debugging and profiling tool you use during development on your own machine, not a performance monitoring tool you put on the server. I think you've just misunderstood it's use case. For development profiling and debugging xDebug is what you want. To wit, new relic and blackfire can't debug, and xDebug can't monitor.

I appreciate they serve different purposes, but I had some unknown bottlenecks I wanted to discover, and explored 3 ways of doing so. In my case, one was far easier to actually gain any insights from than the others :) FWIW I use Xdebug regularly during development anyway.

Ah I see, my mistake, yes I wouldn't look to xDebug to track down performance issues admittedly, it's too cumbersome and limited as you've noted. My use case for it's profiling is simple comparisons between changes, to see if what I've done did infact improve a specific performance issue. New Relic is a godsend when you're trying to track down production performance issues, especially of the intermittent kind.

Last time I looked NewRelic's PHP experience wasn't quite there. Blackfire has been advertising an APM for ages but when I checked in April it still wasn't released to everyone.

The one which never seems to appear on Google when people go looking for one is https://tideways.com/. I've used it multiple times with clients and it finds the problems in minutes.

Another up-and-coming PHP profiler is from DataDog. Again, not a dedicated PHP tool like Tideways so I found the experience lost out a bit (plus the per-server pricing didn't work for us with multiple machines in a HA setup)

PHPStorm natively integrates xDebug and profiling, really handy to be able to just kick off a debug or profiling session from your IDE. xDebug also handles remote debugs, so if you're super stuck on an issue that only happens in production you could remotely debug the application with xDebug (often without affecting the application for other users)

Xdebug is great for... debugging! It has a huge footprint and your metrics just don't mean anything.

Btw, the concept of altering the result of what you are observing by the fact of observing itself doesn't remind you of Schroedinger's cat? :)

Reply on news.ycombinator.com