docker-magento
docker-magento copied to clipboard
Add php-spx profiler
php-spx can be alternative to blackfire or can be used as additional tool to analyze timelines as it shows more details.
The package needs to be added in container
zlib1g-dev
config added for FPM
process.dumpable = yes
in php.ini zlib.output_compression should be disabled to make it work with nginx
zlib.output_compression = 0
First, thanks for the PR!
Second, how does this differ from Xdebug's profiler? https://xdebug.org/docs/profiler
I haven't heard much of SPX, is this common for other PHP devs to use?
It has different purpose than xDebug. As I described it is more an alternative for backfire with more detailed timelines, (when in blackfire timelines are part of paid subscription) it has built-in UI, low overhead, it's open source and easy to use. Mainly can be used for analysing deep magento call-stacks via flame graphs/ timelines (to understand what is going on under the hood) and performance optimisation.
Thanks for the info. I'm going to hold on this now until some updates come in.
- I don't want to disable
zlib.output_compression
, as this will slow down all sites that do not want to use this (which is the vast majority). I think we should leave it on, and if someone wants to use this, they will need to toggle it off. - The code checks out code directly from a GitHub repo. Ideally, we'll need a snapshot of a specific version, because this repo can change at any time, breaking this functionality.
regarding 1: it requires by this profiler. Maybe new script can be added php/spx
to enable/disable the extension
regarding 2: can be fixed to specific tags not master if you want
Recommend: git clone --depth=1
for shallow clone to save image size
Thanks for the info, I think it makes a ton of sense to bring this in. Needs a few updates, so I'll need to review this one.
- Added PHP-SPX profiler to the project
- Updated README file with instructions on how to use it
Hi @ilnytskyi,
Thank you for the PR. I have been searching for an alternative to the overpriced Blackfire, and this is certainly worth exploring. I've applied your PR to my local installation, and it worked on the first try.
Unfortunately, Blackfire removed its free tier, and now it requires a yearly subscription even for local debugging. (FYI @markshust)
I made a lot of updates to this PR to rebase & get them to build on the current images. The image builds fine, but when testing out a page load, it spins for quite a little while and then returns an error when attempting to load the home page.
Never mind... user error! I was trying to load the wrong site URL.
I'm now seeing this. How can I start profiling?
SPX looks enabled:
@markshust it's been some time after I originally posted this PR.
I can add some new info. Now .so extensions can be grabbed from releases instead of compiling https://github.com/NoiseByNorthwest/php-spx/releases
But compilation time is not that long and docker images must be built anyway.
By default profiler writes dumps into /tmp
however I changed it to /var/www/spx_dump
to manually delete or share with others. Here is the bug/feature, spx can create only one level folder. It does not create folders recursively.
To profile:
CLI: use env vars just prepend them to command. There is a hint in a UI
Web: Just add same vars as cookies to request. In browser they are added automatically from UI, then just go to pages, refresh UI to see dumps.
I found some videos might be more clear e.g. https://www.youtube.com/watch?v=xk-JiBLsKfA
How to use: I am sure once you managed to setup it properly you can make a whole new next-level courses about reverse-engineering for magento and performance analysis. No more magic happening in php as everything visible on the timeline.
I also saw some guys tried to export dumps to OpenTelemetry traces, but in my opinion Sentry + Excimer might be more handy solutions. From my experience spx works best for local and stage/pre-prod environment. To use in prod, it's better to deploy separate instance hidden behind some auth as default spx security is weak and can be easily omitted or misconfigured.
It's is possible to achieve similar SPX-like profiling experience with xDebug, but xDebug has huge tracing overhead. I attempted to prepare a helper tool https://github.com/ilnytskyi/xdebug-to-chromium-trace-converter however with current xDebug performance it appeared to be useless for magento. Only ok for small scripts. So spx still the fastest.
Thank you! That video helped a ton. I just didn't know how to get the traces with the UI.
This is working for me. We need some documentation added so I don't get an influx of tickets with people wondering how to use it, but I'll put something together for this at least initially, and then work on more stuff for it.
I agree this can definitely open up some doors with debugging and additional analysis. Thank you so much for the extra info and background, it definitely helps me out.