Comment by jw1224 | Hacker News Reader

Comment by jw1224 | Hacker News Reader

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/

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.

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

+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.

Reply on news.ycombinator.com