Systems | Development | Analytics | API | Testing

One of our recurring jobs at Tideways is to ensure that all of our instrumentation works with new and upcoming PHP versions. For us, “working” doesn’t just mean that the results are correct, but that your PHP extension is fast, gathering insights for our customers with a minimal performance overhead.

FrankenPHP bills itself as “The Modern PHP App Server” and provides a single-process solution to running PHP. Its worker mode allows to greatly increase the performance of cleanly developed applications that are compatible with it by saving on framework bootstrapping time. Unfortunately, not every application is compatible with worker mode. Depending on the amount of global state kept by the application, updating it for worker mode is not always easy.

Welcoming bots and crawlers to your site is a necessary part of operating any web application or e-commerce store. That relationship turns sour when they engage in excessive behavior and adversely affect the performance for regular users. Our customer Greenstories experienced a 10-fold slowdown in performance and a failure rate of 6% over a few hours when a crawler visited their store and messed with the Shopware cart functionality.

How does your Shopware 6 store’s PHP backend performance compare to other operators of Shopware in general? To answer this question, we have aggregated and anonymized performance data from over 200 Shopware 6 stores over the last quarter and computed benchmark numbers to compare to for the most important page types.

The close of 2024 is near, and that also means a new version of PHP is about to be released: 8.4! There has already been some discussion regarding the latest features and modifications affecting developers, for example on either stitcher.io or php.watch. We wrote this post with a totally different angle, highlighting the performance, debugging, and operations-related changes in PHP 8.4 that are usually less publicized. If you are here to find out: Is PHP 8.4 faster than previous versions?

In our third Release of 2025, you’ll uncover new ways to correlate data, debug critical bottlenecks, and streamline your workflow. Over the last few months, we have been working on powerful new features and refinements for you; designed to give you more in-depth visibility, more automation, and smoother workflows. We’ve added Performance Correlation in our service overview, so you can now spot dependencies and degradations system-wide at a glance.

How does your Magento 2 store’s PHP backend performance compare to other operators of Magento in general? To answer this question, we have aggregated and anonymized performance data from over 70 Magento 2 stores over the last quarter and computed benchmark numbers to compare to for the most important page types: Product details, Category Page, Search, and Homepage.

Every once in a while when browsing through open-source code, you will probably have come across internal functions that are either imported implicitly with use function array_map; like here in Doctrine or prefixed with the global namespace separator, for example \is_string($foo) like in Symfony. Curious beings as we are, you might wonder as did I: Why are they doing this? Do function calls not automatically fall back into the global namespace?

Autoloading performance affects every PHP application. And no, it’s not a solved problem just because Composer handles autoloading for you nowadays. In fact, for large applications like Magento, Shopware, or those based on Symfony or Laravel, autoloading can turn into a major performance bottleneck. More than 100 ms per request is not uncommon, caused by one of these common mistakes: Let’s break it down.

Thinking about enabling OPcache Preloading to squeeze more performance out of your PHP application? It’s an advanced feature with very specific benefits — and in most cases, you likely won’t notice a difference. In this post, we’ll explain what OPcache Preloading is, how to set it up, and when (or if) it makes a measurable impact.