Systems | Development | Analytics | API | Testing

Learn more about one of the most important levers for optimal PHP performance. OPcache provides support for byte-code caching of PHP scripts. For a dynamic language such as PHP, a byte-code cache can increase the performance significantly because it guarantees a script is compiled only once. OPcache has been bundled with PHP as a loadable extension since PHP 5.5. Starting with PHP 8.5 OPcache is an integral part of PHP and always installed, but not necessarily always enabled.

We’re rolling out a new wave of improvements across Tideways in our first Release of 2026, focusing on deeper visibility, smarter automation, and broader ecosystem support. From automatic tracepoints for selected transactions and improved exception workflows to enhanced FrankenPHP worker-mode instrumentation, these features continue to reduce manual effort while increasing observability.

In the blog post about Fine-Tuning OPcache Configuration I mentioned the thundering herd problem that affects OPcache during cache restarts. When OPcache is restarted, either automatically or manually, all current users will attempt to regenerate the cache entries. Under load this can lead to a burst in CPU usage and significantly slower requests.

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 second half of 2025 and computed benchmark numbers to compare to for the most important page types: Product details, Category, Search, and Homepage. We previously made these benchmarks for 2025 Q1, and 2025 Q2. Going forward, these will be published every 6 months.

Big optimizations in PHP’s memory consumption have become exceedingly rare. Since then, memory improvements have been smaller in scope, focusing on little details for certain types of variables. Like improving the Garbage Collector (GC) in edge cases, which Iljia Tovilo contributed to PHP 8.5 titled “Mark enums and static fake closures as not collectable”.

In our fourth Release of 2025, we included PHP 8.5 support on the day of its release and Heartbeats to monitor your application’s pulse more closely than ever. If something is offbeat, you’ll receive timely alerts. We improved alerting by introducing fine-granular transaction level response time and made automatic tracepoint triggers more powerful.

Each year, right on schedule, a new version of PHP is released at the end of November. So, how much faster is this new release across popular frameworks and applications? Our tests show that, in general, the performance between 8.2, 8.3, 8.4 and 8.5 does not move much for a Laravel, Symfony and WordPress demo application. Moving to the newest PHP version isn’t a magic shortcut to better performance. Not everything is bleak, though.

The close of 2025 is near, and that also means a new version of PHP is about to be released: 8.5! There has already been some discussion regarding the latest features and modifications affecting developers, for example on Laravel News, PHP.Watch or the Zend Blog. In this post we are highlighting just the performance, debugging, and operations-related changes in PHP 8.5 that you will not find in the posts listed above. Several of these changes were even contributed by Tideways employees.

We are noticing that some of our requests are starting to get slow and server load increases. Checking the process list of our server, for example with htop reveals that our FPM workers are taking up all of our CPU time. Checking the health with our basic toolset of lsof to show open network connections and strace to show syscalls does not reveal any activity. This means that the workers are spending time processing data without any externally visible activity.

The database is often the source of performance problems in PHP applications, but there are many different reasons why this is the case. The most straightforward is that individual queries that the application issues are slow, due to their inefficient structure, by not using indexes or other coding mistakes. But for MySQL databases, a common problem is also the misconfiguration of the server itself.