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/....).
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.
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…?!
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)
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.
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.
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)
PHP has changed a lot since 2012 when that article was written, both as a language and as a community. But I would say even back when this person wrote that article, they were just bummed that it wasn't the language they actually wanted to use. PHP is a perfectly capable language, you can get stuff done in it, not every piece of code needs to be an homage to computer science.
Not much have changed in PHP since 2012, relating to his exact criticisms. I've yet to meet a good developer who likes the language, but I've met many who like it.
Cute quip but you've not made your point. The PHP core team have added numerous large core language improvements to continue to enable very modern software development, many do in fact touch on points in the article. Perhaps the authors pet-peeves are just not that important to the core team and to the people are using the language for real work.
Can you suggest another language that effectively allows inline templating like PHP does, and has a huge set of libraries available?
PHP runs more of the "web" than you probably realise - some of the highest trafficked websites in the world, in fact. It's fine done properly. The bad press from 20 years ago is pretty much unwarranted these days. Also, if wordpress had been written in RoR or Perl/something else, plenty of the PHP bad press would have been avoided.
There are too many to mention, even Clojure supports inline templating, but it's a horrible design pattern. Have a look at Enlive instead if you want something close but solid.
> I've yet to meet a good developer who likes the language
I've yet to meet a Clojure developer capable of actually solving business problems. All they do is pontificate about how perfect FP is and how terrible every other language is, despite accomplishing nothing whatsoever themselves.
Speaks more to your lack of judgement abilities than a rule or trend. Do you get many applying for a job supporting your todo app? Curious how much mrr ZimTik has reached.
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/....).