Great application performance is crucial because it impacts user experience, business success, and operational efficiency. When we currently observe mostly focus on frontend optimization, let’s not forget about the backend. A new, fresh, and fast front will not be able to deliver what’s promised if the backend still responds slowly. An unoptimized backend is not only slow for the end-user but also makes the load on the server high, which can impact server bills and, in the end, even kill the server on peak customer visits. We need to care about the performance of the Magento backend constantly to make sure that new features don’t break the operations.
The obvious choice for performance monitoring is an APM (Application Performance Monitoring) tool like New Relic, even on the free version. Such a tool gives you insight into how the application is doing in production. It can point out the slow endpoints and slow database queries, and just show us where to look for performance bottlenecks, but such tools are not ideal for profiling the performance and determining what’s wrong.
A more specialized tool for profiling is needed, and we have few options.
Magento built-in profiler: you can enable it with Magento CLI via dev:profiler. It is aware of all Magneto elements. It recognizes events, observers, and layout processing, so you can easily recognize key parts in the output. The problem is that the output is a list; it’s quite hard to spot problematic methods or expensive loops. When it comes to efficient profiling, it’s not that good.
There are commercial products like Blackfire. It can offer profiling on even production environments, which can help you spot bottlenecks in the actual environment where they happened. Blackfire offers nice Flame graphs that help recognize problematic code much faster. The only downgrade is prices; monthly licenses can be quite high for small to mid-store Clients.
This is where PHP SPX comes in. SPX is an open-source profiler for PHP. S stands for Simple, but it’s very powerful and can be overwhelming at first.
PHP SPX
(https://github.com/NoiseByNorthwest/php-spx) It is a great tool to profile requests, spot bottlenecks, and find pain points.
It has function-level profiling that measures the execution time, memory usage, etc. You can check how much of the function execution time was spent inside the function and how much in other methods called by this function. Thanks to that, you can quickly find expensive functions or functions that lead to costly nested invocations.
SPX has nice graph visualizations. It generates interactive flame graphs and call trees. You can zoom in on specific parts of the graph to get more insights and see small functions that are called. Thanks to its interactive graphs you can have a top-level look at the request execution and then zoom in on the specific points that you want to examine.
In Web UI, you can examine profiling reports, search for specific classes or methods, and click on them to see where it is executed and what impact they have.
SPX profiling adds minimal overhead to the request execution time, so it can be used without problems on a daily basis.
SPX is included in Mark Shust’s Docker Magento project, making it easy to start working with. You enable it via CLI (bin/spx), and then you can access the Web UI by adding “?SPX_KEY=dev&SPX_UI_URI=/” to your local domain to enable profiling and check reports.
You can also configure SPX in a remote environment (even production). It has an IP whitelist, but as stated on the GitHub repository, it’s not production-ready. I recommend using it only on local environments or some closed staging environments.
Profiling Magento with SPX
You can profile requests in developer and production modes. To make more stable results, change Magento to production mode in your local environment. Enable profiling, and start with default settings. You can adjust measured metrics and sampling when needed, but the default configuration is fine enough to start in-depth profiles.
After configuration, you can visit the page that you want to profile, then go back to the SPX Web UI panel, and at the bottom of the page, there will be a record for the visited page (and other related requests). Click on the interesting one to open a profile analysis tool.
It contains three views:
- On the top – call timeline (span chart) – you can spot when functions ran. Tall bars or long spans represent slow calls.
- On the bottom-left – flat profile table of functions that can be sorted out by metrics, you can quickly spot functions that run multiple times or take a lot of request time.
- On the bottom-right – flame graph – you can spot hot call paths, which aggregate identical stack paths (repeated calls) into a wide bar. Useful for N+1 issues.
At the top, you can choose metrics to explore, by default, wall time, and search for specific functions. This is especially useful if you want to check how much time it takes to execute code from a particular module or vendor. When you click on a function, it will be highlighted in other views. This makes it easier to spot where the function is executed. Every function has metrics “Wall time exc.” and “Wall time inc.” the first one shows how much time is spent inside the function, and the second adds the time of all calls made by this function.
Slow or redundant SQL queries and other external calls are not shown directly in SPX, but you can check how much time is spent on them by searching for the function that executes them, such as Magento\Framework\DB\Adapter\Pdo\Mysql::query.
SPX also has the possibility to profile CLI and long-running processes. Everything is described in the GitHub repository, so I encourage you to check it out.
Taking care of application performance it’s not something that should be done in those few hurrah moments when someone looks at a slow backend and decides that we need to finally optimize it. Instead, performance testing should be part of CI/CD and the development process; every developer in the team should test how changes that are introduced are impacting performance. Everyone should be responsible for taking care of application performance, and this should be a part of day-to-day work. Of course, sometimes the deadline is pushing things to make it quickly. The quality is pushed to second priority, but to keep technical debt manageable, the revision of this code should be planned for the next sprint or so to make sure that we don’t leave code issues that will be stuck up to the bigger problem in the future. It’s easier to deal with small issues when they still are not a production problem than to fight fires on peak days like Black Friday.
Be First to Comment