[HN Gopher] How to profile your PHP applications with Xdebug
___________________________________________________________________
How to profile your PHP applications with Xdebug
Author : mooreds
Score : 53 points
Date : 2022-05-06 13:07 UTC (1 days ago)
(HTM) web link (www.vincentbroute.fr)
(TXT) w3m dump (www.vincentbroute.fr)
| pachico wrote:
| 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? :)
| idoubtit wrote:
| 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/....).
| stefanfisk wrote:
| 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.
| codegeek wrote:
| XDebug is good for debugging code in development environments.
| Not for profiling in production.
| lbj wrote:
| ehnto wrote:
| 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.
| lbj wrote:
| 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.
| asddubs wrote:
| haha, sounds like a self fulfilling prophecy. someone says
| they like php and you think "wow this person sucks"
| datalopers wrote:
| > 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.
| ehnto wrote:
| 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.
| trollied wrote:
| 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.
| lbj wrote:
| 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.
| ezequiel-garzon wrote:
| Could you provide a link to Enlive? I can't find anything
| relevant. Thanks!
| [deleted]
| ehnto wrote:
| 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)
| jw1224 wrote:
| 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/
| blowski wrote:
| > Blackfire - Terrible UX
|
| NewRelic is obviously fantastic, but it doesn't have the deep
| PHP-specific info provided by Blackfire.
| pbowyer wrote:
| 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.
| pbowyer wrote:
| 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)
| CSSer wrote:
| 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.
| djbusby wrote:
| Might want to look at syslog() vs calls to error_log().
| agrunyan wrote:
| +1 for the helpful comparisons! I'll definitely be checking out
| New Relic on Monday, sounds exactly what I've been looking for.
| ehnto wrote:
| 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.
| jw1224 wrote:
| 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.
| ehnto wrote:
| 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.
___________________________________________________________________
(page generated 2022-05-07 23:01 UTC)