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.

Are you mostly curious whether PHP 8.5 outperforms earlier versions? Take a look at our benchmark.

Performance

OPCode specialization for === []

The PHP compiler can optimize opcodes to run more efficiently, and for 8.5, my colleague Tim added an optimization for the $array === [] check. Before, this way of testing for an empty array was the slowest when compared with !$array, count($array) === 0 or empty($array).

In PHP 8.5 this becomes the fastest way of testing for an empty array. Should you change all code now? No. But it shows that when you micro-optimize code, you might lose that benefit in a next PHP version when the engine evolves and an entirely different code path is faster now, and maybe it’s best to just write what you find most readable and bet on future engine improvements.

I made a video about this change a few months ago: Stop Micro-Optimizing Your PHP Code (Unless You Rely On This).

Optimize match (true)

Another compile time optimization that Tim made for 8.5 is to reduce the number of opcodes that are emitted when you have a match (true) statement.

For an artificial code example such as the following, this provided a 17% (+/- 6%) improvement:

Persistent cURL Handles for DNS, Connection, and SSL Handshake Reuse

PHP’s shared nothing architecture is very helpful in avoiding memory leaks and accidental data leaks between users. But it has its downsides when you are performing the same work in each request over and over again.

For example, DNS, Connection, and SSL handshake times in cURL HTTP requests.

With PHP 8.5, you can now cut this time down significantly by sharing the DNS, connection, and SSL handshake information between HTTP calls made from different PHP requests using a new function, curl_share_init_persistent.

When you run this piece of code multiple times in a web server with PHP 8.5, you see how the second call gets much faster and by how much looking at the cURL timers:

This change was contributed by Eric Norris through the “Add persistent curl share handles” and “Persistent curl share handle improvement” RFCs.

I recorded a video on cURL share handles with a detailed example and numbers.

Improve Performance of Instantiating Exceptions and Errors

Generally, exceptions shouldn’t happen often in PHP applications, but there are cases where they are either by accident or fully on purpose. This got slightly faster with this PR by Niels Dossche. It moves some checks to debug builds of PHP and skips them in production builds.

Improved Function Performance

The following core functions got performance optimizations in PHP 8.5: array_find(), array_filter(), array_reduce(), usort() / uasort(), str_pad(), implode(), pack(), and ReflectionProperty::getValue() + variants.

Operations

OPcache is now a required Extension

With PHP 8.5, OPcache is now a required extension, automatically built into every PHP binary, thanks to this RFC by Tim, Arnaud, and Ilija. There is not an option to run PHP without it anymore or accidentally forgetting to install it, which was a common problem with Docker containers using the php Docker Official Image.

The goal here is to simplify maintenance and allow making use of the Optimizer part of OPcache in a simpler way and share/move code to the engine.

It’s still possible to disable OPcache through php.ini settings.

OPcache File Cache Read-Only Support

Before PHP 8.5, you could not use the file cache of OPcache in combination with a read-only filesystem. This made it impossible to benefit from the file cache in container setups where the deploy and run steps are separated. In these scenarios the cold startup time is something heavily optimized, for example on AWS Lambda when running bref.

This PR by Samuel added a new INI option opcache.file_cache_read_only. With this option set, OPcache does not invalidate files anymore and does not run code that would modify the filesystem.

The PR mentions it should be combined with the settings opcache.validate_timestamps=0, opcache.enable_file_override=1and opcache.file_cache_consistency_checks=0 for best results.

The PR also includes a firsthand experience from bref author Matthieu Napoli, who mentioned he saw a 100ms drop in cold startup times on AWS Lambda for a test application.

New max_memory_limit INI directive

Before PHP 8.5, you could essentially change the memory limit to unhealthy high numbers by calling ini_set("memory_limit") without guards. This can now be prevented by configuring the system INI setting max_memory_limit which defines the upper limit of how high the memory limit can be set at runtime. The change was contributed by Frederik Pytlick in this PR.

Add new PHP_BUILD_PROVIDER constant

Tim contributed another small change that can be very helpful to general application. It was already possible to compile PHP with the PHP_BUILD_PROVIDER environment flag to provide information on who was responsible for the build. This was shown in phpinfo() and php -v outputs. With a new PHP constant PHP_BUILD_PROVIDER you can now also access this information at runtime.

Various people also already worked this into upstream PHP builds of Homebrew, Debian, Docker, and Fedora.

Debugging

php --ini=diff

With a new option on the command line, you can now see a list of all INI variables that were changed from the default value. This will be very helpful for debugging and bug reporting your PHP installation.

Add runtime-enabled heap debugging capabilities

With this PR from Arnaud, PHP 8.5 gains memory debugging capabilities without having to compile it with specialized tools like ASAN/MSAN/Valgrind, which might be hard to come by in production. Our colleague Tim worked on this as well, as we have had this capability wish when debugging Tideways PHP extension on customer systems a few times.

By setting the environment variable ZEND_MM_DEBUG you can enable different memory debugging functionality.

Error Backtraces

Fatal Errors that are outputted from PHP now show the backtrace by default thanks to this RFC from Eric Norris. Previously a fatal error would only show the message.

New functions: get_exception_handler(), get_error_handler()

With this RFC from Arnaud, two new functions were added to PHP 8.5 that give access to a callable of the current exception or error handler through two new functions: get_exception_handler and get_error_handler.

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. And MySQL has a single setting that is overwhelmingly responsible for the performance, called InnoDB Buffer Pool Size.

The setting declares how much of the database tables and indexes can be cached in memory (RAM). MySQL performance experts recommend keeping all data and indexes in memory.

Because databases are usually growing over time, this setting is not a “once and forever” setting, but it should be re-evaluated from time to time.

So if you are experiencing slow database queries, before blaming the individual query, you should always keep in mind to check if the database is too big for the InnoDB Buffer Pool.

Because if the database is too big, then depending on the application usage patterns, InnoDB keeps changing what it stores in memory constantly, always purging data again from the cache, and re-loading it from disk at high expense when its needed again.

Determine current setting of InnoDB Buffer Pool

To find out what the current size of the InnoDB buffer pool is, you can issue the following queries against your MySQL database:

In this case its 8 MB of memory. An extremely low value! The default value according to the MySQL docs is 128MB, however different distribution packages might already change that to something different.

Determine InnoDB Buffer Pool Cache Hit Rate

There are several ways to determine the current buffer pool cache hit rate. On the internet you often find instructions run the following command, looking at a huge blog of text of unstructured data.

The output is rather large so that sometimes it makes sense to set the pager tool to less before:

Search for the section “BUFFER POOL AND MEMORY” it will look like this:

You find the note “Buffer pool hit rate” at the bottom and it shows a 1000 / 1000, which is the best value you can get.

There is a better way to get this information from MySQLs internal data tables:

This can also be calculated through two global status variables, and you can run the following SQL query to get the same value:

Outputs:

This gives a hit rate of 99,999%, or a 1000 / 1000 as calculated in the InnoDB buffer pool status.

This is a very good value, but when its worse than 90%, then this usually means that too many reads are not hitting the buffer pool as mentioned before.

InnoDB status seems to multiply the percentage by 1000 instead of 100 to get “human readable” values, 971.975 essentially means 97,1975%.

But what time frame are those numbers relating to? Reading the MySQL docs very carefully it seems that the following is true, though I am not 100% sure about this. Please comment if you know more.

If you want to calculate how high the number is in a fixed time window, you need to store the variables innodb_buffer_pool_reads and innodb_buffer_pool_read_requests regularly and compute the hit rate on the difference of consecutive measurements.

This blog post on INNODB SHOW ENGINE STATUS walk-through by renowned MySQL performance expert Peter Zaitsev of Percona has little additional information about a good or bad value, but mentions that it depends on the application when a bad cache hit ratio starts leading to increased I/O.

How big is my MySQL dataset including indexes?

To understand how big the InnoDB Buffer pool should be, you need to look at how big the dataset actually is and there is this handy query that you can run to find that out:

For my Shopware Demo shop application this results in the following, with most rows cut for readability:

You can see the size in MB of individual tables, and the “rollup” meaning the sum over all the tables combined. Here we have 132MB of data in the database, which is not very hard to all keep in memory. Even with the just 8 MB Buffer Pool from above, the Hit Rate is at 97% when just browsing through the UI, because not all of the 132 MB are needed.

Contrast with the Tideways database, which currently has 300 GB of data. It still achieves a nearly 100% cache hit rate, because the “working set” of data is much smaller. About 290 GB are historical data that are rarely read.

The query for the data size thus only gives the upper limit of what you might need for the InnoDB Buffer pool size. Each application is different with respect to what its “working data set size” is.

Changing the InnoDB Buffer Pool Size

Now to the final important piece, changing the value. This should be done on server startup and requires root access to the Database server, or maybe is changeable through the control panel of your hosting or cloud provider. There is most likely a mysqld.conf somewhere in /etc/mysql or a subfolder, this differs between Linux distribution.

In this file you either already find the setting, or you add the setting with the value you want and restart the MySQL server afterwards:

If you want to change the value at runtime without restart, that is also possible. But be aware that it reverts back to the configured server value when restarted without changing the configuration:

See the MySQL documentation for more information on changing this value.

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.

While we have a comprehensive automated test suite, especially for new PHP features or library updates, sometimes we manually investigate – and one of our main tools for this job is hyperfine.

What is hyperfine

Hyperfine is a command-line benchmarking tool that takes care of handling the challenging parts of performance measurement correctly. By presenting execution times in a reliable, consistent and human-readable way, it ensures clear communication of the results. Beneath the surface, hyperfine also takes care of all the minute details that pose a challenge during benchmarking, thereby making it easier to get good and correct results.

All you need to do is pass it different command invocations, and it will compare them using multiple executions to get reliable data..

Let’s start with a simple example. We run the sleep command for one, two and three seconds.

The output shows us that “sleeping for 1 second” was 1.98 ± 0.01 times faster than “sleeping for 2 seconds”. One of the things to note is that hyperfine always shows you the measurement uncertainty.

With sleep this uncertainty is very low, showing 1.020 s ± 0.006 s, meaning the execution is confidently measured to take 1.014 to 1.0026 seconds. Other programs can have a lot more variance and therefore uncertainty.

For example, when comparing 603.9 ms ± 170.8 ms and 502.1 ms ± 400.8 ms we can’t make any statement regarding what is actually faster, as the errors overlap too much. Being mindful of this can be very useful to focus on meaningful improvements.

Measuring PHP performance

Now, how does that work for PHP?

We test two main things: The same PHP code with different PHP binaries, for example different versions or build flags, and different PHP code with the same binary.

Let’s look at PHP 8.4’s sprintf optimization as an example.

In the following test, we run a million sprintf calls using PHP 8.3 and PHP 8.4:

hyperfine '/opt/php-8.3/sapi/cli/php bench-sprintf.php' \
     '/opt/php-8.4/sapi/cli/php bench-sprintf.php'

In cases where the command gets quite long, for example, when adding ini settings with -d we can also use Hyperfine’s placeholder parameter.

hyperfine -L version 8.3,8.4 \
  '/opt/php-{version}/sapi/cli/php bench-sprintf.php -d opcache.enable_cli=1'

Testing on the CLI: Be mindful of OPcache

By default, OPcache isn’t enabled for CLI scripts. This is done to avoid the cost of the optimization for one-time scripts. For our case, we want to use OPcache as this will provide the relevant insights for web-requests or long-running scripts:

hyperfine '/opt/php-8.3/sapi/cli/php -d opcache.enable_cli=1 bench-sprintf.php'  \
   '/opt/php-8.4/sapi/cli/php -d opcache.enable_cli=1 bench-sprintf.php'

Here we see PHP 8.4 executing 1.47 times faster, already an impressive difference, but we’re also still paying the cost of the function calls, which also adds some overhead.

So let’s isolate the change to just the sprintf call.

And see how the numbers change:

hyperfine -L version 8.3,8.4  \
   '/opt/php-{version}/sapi/cli/php -d opcache.enable_cli=1 \
   bench-minimal.php'

Over six times faster! Measuring things and making definitive statements is always tricky, and it’s easy to get things wrong. If we, for instance, forget to enable OPcache, the example above only shows a 1.8x difference between PHP 8.3 and 8.4 instead of the over 5x we’re seeing here.

When testing with PHP versions before PHP 8.5, it’s also possible that the OPcache extension isn’t loaded and PHP will silently ignore the OPcache ini settings, invalidating the results. Double-checking with php -m | grep -i opcache or with some code in the test script can prevent that issue.

This happens because of our simple test case. Now that PHP 8.4 can turn \sprintf into an interpolated string containing only literals, OPcache will recognize that this string isn’t used and optimize that out. Using a couple of variables as parameters or assigning the result to something will change this behavior. Try it out yourself! A lot of the value in benchmarking comes from being surprised and then learning something while trying to explain the results.

Benchmarking code chances

Now let’s make some comparisons within one PHP script:

hyperfine -L mode with_backslash,without_backslash  \
   '/opt/php-8.4/sapi/cli/php -d opcache.enable_cli=1 bench.php {mode}'

Over 1.3 times faster by adding a single character, or using the equivalent use function sprintf import.

Here, we can nicely see that the optimization only takes effect when PHP can see that sprintf is the global sprintf. Without the \ PHP needs to look up if a locally defined \bench\sprintf namespaced function exists, and thus PHP can’t optimize the call for you.

Note that this specific optimization is not performed by OPcache, but rather happens in the compiler itself. Other types of optimization are specific to OPcache though. Hence, we suggest you always turn it on to make sure your tests match how you will later run your code.

Outro

We hope this serves as a nice overview of benchmarking with hyperfine and showcases some key considerations to keep in mind when testing PHP.

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.

For completeness, we investigate if FrankenPHP in “Classic Mode” is also able to speed up your application. Prior research by Ivan Vulovic in https://vulke.medium.com/frankenphp-vs-php-fpm-benchmarks-surprises-and-one-clear-winner-173231cb1ad5 suggests it is – but the numbers seem a little too good to be true.

In this blog post, we aim to verify these results with the explicit goal of testing PHP runtime performance itself, and not the performance of PHP script execution, Linux scheduler, web server, or other influences. Our results show that there is essentially no performance or throughput difference between PHP-FPM vs. FrankenPHP Classic-Mode.

Benchmark Setup

As in our previous article comparing the performance of different PHP versions across popular applications, we’re using a Hetzner VPS with 8 dedicated vCores on an AMD EPYC 7003 or EPYC 9004 (Hetzner CCX33). This time, the operating system is the newly released Debian 13 (“Trixie”).

We’ll be comparing FrankenPHP v1.9.1 (PHP 8.4.12 Caddy v2.10.2) against nginx/1.26.3 paired with PHP-FPM 8.4.11. The measurements are performed using Vegeta v12.12.0.

We’re installing FrankenPHP as a Standalone Binary using the recommended curl |sh command. Both nginx and PHP-FPM are installed using Debian Trixie’s official package repositories.

After installation, we only make a small change to nginx’ configuration, adjusting the port to avoid conflicts and to enable the PHP configuration block provided by Debian.

At this point both FrankenPHP and the nginx+FPM combination run with their default configuration, without any performance tuning.

Given that we want to measure the overhead added or removed by selecting a different runtime environment and not the performance of PHP itself, we’re going to test with simple scripts that do not contain any actual business logic.

In addition, we are not testing with a lot of concurrency; instead, we spawn 1 worker per CPU. For the full Vegeta output including more throughput and response percentiles click on the “test label” in the first column of each result table below.

Testing HTML Response Generation

A common server-side rendered HTML landing page contains about 50 KiB of data, so let’s use this one as the basic benchmark:

Across this 60-second benchmark with 8 clients hammering the server as fast as possible, the nginx+FPM combination was able to serve 7023 requests per second (with overall better latency), whereas FrankenPHP in classic mode could serve 6934 requests (with a little better maximum latency). Nginx+FPM are thus roughly 1.3% faster than FrankenPHP in classic mode. Not enough to really matter.

Case closed? Not yet. A landing page is just one of the cases you’re going to experience in your application. What if, for some reason, the results change for other use cases?

Testing Binary Response Generation

Instead of an HTML response, let’s try a binary response format, for example, PDF:

It seems that FPM got faster (with even better latencies) and FrankenPHP got slower, only by changing the content-type from text/html to application/pdf, keeping the response exactly the same:

Let’s try again with an “encrypted” base64-encoded payload being embedded into our HTML. Encryption is simulated by random data:

Both FPM and FrankenPHP became slower, but that is expected since the script now does much more work. This time FrankenPHP beats FPM 2.89×. An odd result, that can be explained later in the blog post.

What if we try to do even less work than our landing page example rather than more work? Let’s try with a Hello World example.

Both FPM and FrankenPHP are serving an impressive 18400 requests per second at a 0.4% difference in RPS.

Testing With Higher Concurrency

The article by Ivan Vulovic compared the performance with higher concurrency. While we believe this not to be particularly useful, since we would be measuring the performance of the operating system’s scheduler more than anything else, perhaps FrankenPHP is doing something to be more friendly to the scheduler. Let’s see with the Hello World example that is comparable to the tests done by Ivan Vulovic:

FrankenPHP serves roughly 3.7% more requests per second, but at a much worse latency distribution.

Testing with Optimized Configuration

Up until this point, we were running the “default configuration” for both FrankenPHP and nginx+FPM. Let’s look into some performance tuning.

FrankenPHP provides an official Performance Optimization section in the documentation. No actionable FrankenPHP-specific advice is provided, except for “Don’t use Musl”, which we are not.

For nginx and FPM, there’s no official guide that we are aware of, but we’ve made the following changes:

• Disabled access logs in nginx (matching FrankenPHP).
• Enabled fastcgi_keep_conn in nginx.
• Configured pm=static and pm.max_children=16 in FPM (matching FrankenPHP’s num_threads).

Making these changes did not result in any differences worth mentioning.

Accounting for Output Compression Performance

So, how can all the above results be explained, especially the sudden deviations in the PDF and Random test scenarios?

It appears we were not actually measuring the performance or overhead of PHP-FPM vs. FrankenPHP, but rather the quality of the output compression implementation of nginx and Caddy, respectively.

Vegeta is setting a accept-encoding: gzip request header, and both nginx and FrankenPHP will automatically compress responses coming from PHP when the circumstances are right:

In the case of the PDF example, the response will not get compressed with either FrankenPHP or nginx. In the case of nginx, skipping this compression seems to improve performance; FrankenPHP seems to handle this case of a larger response body not particularly well. On the other hand, nginx is not able to handle incompressible random responses well when attempting to compress them.

We could also confirm this by setting an accept-encoding: identity request header with Vegeta to disable the compression.

Using the landing page example with 8 concurrent requests shows numbers comparable to the PDF invoice when compression is disabled:

We also did some final tests with HAProxy 3.0.11 instead of nginx as the FastCGI gateway in front of PHP-FPM and were able to squeeze out some additional RPS with even better latency compared to nginx, but not really enough to matter in practice.

Conclusion

As a conclusion, we can confidently say the differences in overhead between PHP-FPM and FrankenPHP in classic mode are not relevant enough to suggest moving to FrankenPHP Classic Mode is always better.

As with our previous benchmarks, we can conclude that your application’s architecture has the biggest impact on performance, that there is no shortcut that will magically make things faster.

Shaving off the last microsecond from PHP’s startup performance will not make an impact when spending several hundred milliseconds waiting for the database.

An APM such as Tideways can help find this kind of offender within your application code.

As for choosing a PHP runtime, use whatever your team is comfortable with already.

1. When using Caddy with PHP-FPM, moving to FrankenPHP can reduce operations complexity.
2. When you want to benefit from one of the FrankenPHP exclusive features, like 103 early hints, Go extensions, or Mercure realtime support, a move from PHP-FPM to Classic mode might make sense.
3. In other cases PHP-FPM still has an edge in performance when your application code is already optimized but not yet ready for worker mode.

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?

Yes they do, you don’t technically need to use function or prefix with the global namespace separator.

But there is another technical reason why open-source libraries do this: A small number of PHP internal functions has compiler optimized versions that avoid a lot of the internal overhead of an internal function call in the PHP engine. You can find these functions in the zend_compile.c file of PHP.

You might raise the point that this sounds like a micro-optimization and you are correct.

For open-source code you can argue that it should be a matter of good style to provide the lowest overhead possible.

For your own application code, this optimization is less important but there are cases where this optimization does matter as well: When you call these compiler optimized functions hundreds of thousands of times and your application has low response times in the 20-200ms range.

Granted, these cases are rare – but its good to having heard about this optimization nonetheless.

Should we stop here? No! Two topics are interesting to look into with compiler optimized functions:

• Benefiting from the optimization by relying on code formatting automation
• Can we measure compiler optimized functions in a Profiler and how would that look like?

Automatically import compiler optimized functions using available tools

When you are using a modern auto-formatting tool such as php-cs-fixer or phpcs with phpcbf already, then importing these optimized functions doesn’t even require a lot of work and can be fully automated. If that is the case, you can benefit from this optimization at nearly zero costs, you don’t even have to know or think about it.

For php-cs-fixer there is the native_function_invocation rule with the default configuration setting @compiler_optimized:

For phpcs you can use the SlevomatCodingStandard.Namespaces.ReferenceUsedNamesOnly sniff from slevomat/coding-standard, but be aware that it does quite a bit more than just importing compiler optimized internal functions.

And then run:

How Profilers see compiler optimized functions

There is something to learn about PHP engine and how profilers work with compiler optimized functions. By implementing the short cut for these few functions in the engine, they also circumvent the hooks that profilers use to detect track the execution.

Take this simple bit of code that re-implements a small variation of str_repeat in userland code and uses strlen doing so:

If we run this through Tideways Callgraph Profiler, Xdebug or any other Profiler you can spot the strlen functions being executed 100.000 times. Because of the missing import from the global namespace, the engine cannot use the compiler optimized version, since a user defined strlen might exist in the MyStandardLib namespace.

See how Tideways already gives you a hint about a potential optimization here, only because it would make an impact on the bottom line of this script, measured at 24% of total execution time.

As a side note: If you are wondering about the shart drop from 7,24ms to 1,81ms, this must be attributed to the profiling overhead that I have written about elsewhere, caused by an otherwise quick internal function called an excessive number of times.

As soon as you add a leading namespace slash to import the function the Profiler does not observe the execution anymore. It looks like my_own_str_repeat is a function that has no child calls. In its 1,24ms execution somewhere the optimized 100.000 strlen functions are hidden:

The Profiler will not be able to detect that strlen is even called anymore, on the account of the PHP engine’s shortcut.

So should you import functions that the compiler can optimize for performance reasons? The answer is: It depends. When the overhead is significant then yes, otherwise you could ignore this as a being too micro an optimization.

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:

1. Not dumping a class map
2. Loading unused classes in every request
3. Expensive prepended custom autoloaders
4. Building your own preloading scripts
5. Not using OPcache preloading

Let’s break it down.

What Is Autoloading Performance?Autoloading performance is distinct from PHP’s compile performance and interacts closely with OPcache.

When PHP encounters a class that hasn’t yet been loaded, it triggers the autoloader system. This involves calling callbacks registered via spl_autoload_register(). These callbacks are executed in sequence until the class is found or PHP throws a fatal error.

Each time this happens, PHP spends time:

1. Running the autoloader callback(s)
2. Calling the constructor of classes
3. Compiling the class (unless already cached in OPcache)

In this blog post we are going to look at point 1: time spent in autoloader callback(s). And while Composer is responsible for this in modern PHP applications, there is still a lot that can go wrong.

As for point 3: Time spent compiling can be reduced to effectively zero by correctly using OPcache as detailed in this post on our blog.

1. Not Dumping a Class Map

Using classmap-based autoloading can significantly reduce overhead.

With Composer, you can optimize autoloading using:

composer dump-autoload --optimize

This generates a autoload_classmap.php file with a precomputed map of class names to paths. The autoloading code then has a shortcut that greatly reduces the runtime of autoloading.

Without a classmap, Composer must run much more complicated code to compute the path for every class and, most importantly, use an expensive file_exists check.

While it seems like an obvious optimization that is well-known, we still see 10-20% of customers are not optimizing autoloaders for production apps, and it would usually cost you 10-50ms in every request, and sometimes even more.

Tip: Always dump your classmap after potentially generating classes in a compile step. This is especially important in frameworks like Magento that auto-generate hundreds of classes.

2. Loading Unused Classes

Autoloading everything on every request is wasteful.

This happens often due to:

• Eager Dependency Injection
• Event systems loading all listeners
• Route matchers loading every controller

Solution: Introduce lazy-loading or cutoffs to prevent loading unnecessary parts of the object graph.

Symfony framework is a good example where this work has happened under the hood over the last major versions. It’s EventDispatcher includes several optimizations where you don’t have to instantiate all listener objects for all events in every request. It does this by passing a factory closure as a listener instead:

With potentially hundreds of listeners and each of them having many dependencies, this can prevent a lot of autoloading happening for classes that ultimately will not be used in the concrete request.

Bonus: PHP 8.4 introduces native lazy-loading support for DI containers, which will greatly improve this situation in the future. See my YouTube video series on Native Lazy Objects in Doctrine (part 1), Symfony (part 2), and Magento 2 (part 3).

3. Expensive Prepended Custom Autoloaders

A chain of multiple autoloaders can be tricky for performance. Composer’s autoloader should ideally be first in the chain—it resolves ~95% of classes quickly with the generated classmap. Then more custom and specialized, potentially expensive autoloaders can run afterward.

Custom autoloaders that prepend themselves to Composer can slow everything down.

Case in point: the older, now abandoned Laminas package laminas-zendframework-bridge prepended an autoloader before Composer’s autoloader to simplify the ZendFramework to Laminas Rename Migration. That package significantly increased autoload times and automatically activated itself as a second-level dependency when using any kind of Laminas package.

Use spl_autoload_functions() to inspect, deactivate, replace, or reorder autoloaders if needed.

4. Building Your Own Preloading Scripts

Preloading libraries manually was popular before Composer matured. Think: Doctrine 1’s “All-in-One” file or Symfony 2’s early class loaders.

But today, these preloading scripts are largely unnecessary and often counterproductive:

• They load too many classes upfront, requiring memory, which costs performance.
• They clutter stack traces and make debugging with XDebug harder
• They reduce flexibility

Modern DI containers like Symfony’s use smarter preloading based on actual runtime needs.

5. Not Using OPcache Preloading

OPcache preloading is a powerful built-in feature since PHP 7.4.

It allows loading frequently-used classes once at PHP startup, keeping them in memory across all requests.

Benefits:

• Skip autoload callbacks entirely
• Reduce file I/O
• Improve response times by 5–10% for fast endpoints

For high-performance apps, OPcache preloading gives an additional edge that you don’t want to leave on the table. See my previous blog post on OPcache preloading for details.

Conclusion

Composer is a fantastic tool, but it doesn’t prevent autoloading from becoming a performance drag.

Avoiding the five mistakes above can save tens of milliseconds per request, which adds up fast.

Want more PHP performance tips? Subscribe to our newsletter or check out the full video for a deep dive with real-world examples.

Stay fast!

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.

What is Preloading?

Preloading was introduced in PHP 7.4, contributed by Dmitry. It allows PHP scripts to be loaded and compiled once at process startup (before any requests), so functions and classes are ready immediately — as if they were built-in.

This is different from regular OPcache, which caches PHP scripts after first execution. Preloading complements OPcache by eliminating autoloading overhead and repeated include/require calls.

The main downside? PHP-FPM or Apache startup time increases, because all preload scripts are executed at once.

When Preloading Makes Sense

Preloading has a few technical pre-requisites:

• Your app is the only one on the server or container
• You’re using PHP-FPM or mod_php
• You can provide a custom preload script

It does not help in setups like Laravel Octane, Roadrunner, FrankenPHP, or AWS Lambda. In fact, it may shift cold start time into boot time with no real net gain.

How to Set Up Preloading

1. Write a preload script This should require all files you want loaded. Symfony does this out of the box. Laravel has third-party support. Or you can write your own. The PHP documentation on Preloading explains the requirements for such a script.
2. Configure php.ini to enable preloading:

When your script from step 1 is called “preload.php” you need the php.ini to point to it. In addition you need to configure the username this script is run with. This should be the same user as the web-server or FPM is running under.

opcache.preload=/app/preload.php
opcache.preload_user=www-data

3. Restart PHP-FPM or Apache Check PHP logs and error tracking (e.g., Tideways) to ensure everything loads cleanly.

What Performance Gains Can You Expect?

In a typical Symfony or Shopware app, autoloading takes around 10–16ms. If the response time of your application is 1 second, preloading might save less than 1%. That’s not worth the complexity.

However, in fast apps that response below 100ms, the story changes.

Example: Tideways Ingest API

We tested preloading on our own application using the pre-generated Symfony preloading script.

The Ingest API receives 30k requests every minute with performance data from our customers. It just authenticates the sender data and then passes it on to a message queue for processing. We expect this API to be very fast to handle the high request volume.

In that case optimizing autoloading performance further will make sense. Before the preloading change we had a 95% percentile response time of 20ms. On average 1ms was spent in autoloading on every request.

After we enabled preloading the 95% response time dropped to 18ms and autoloading time dropped to 0.

That’s a 10% gain.

It will allow us to handle the more of this traffic with fewer resources and save money on server resources.

Conclusion

Preloading isn’t a universal remedy — but in performance-critical, high-throughput environments, it can be worth it.

Use preloading if:

• Your app is well-optimized
• Response times are already low (<100–200ms)
• You want to reduce CPU load at scale to save server resources and increase throughput

For apps with high response times, the relative benefit is negligible. Focus on bigger bottlenecks first.

Need help deciding whether preloading is worth it for your app? Tools like Tideways can measure autoloading and compilation time directly.

A full page cache is a powerful performance optimization for web-applications with numerous visitors.

Instead of performing all the PHP and database work to render the same page over and over again, you cache the resulting HTML once and serve that time and again for a period.

But there is room for even more improvement, especially in e-commerce applications that use full page caching.

Edge Side Includes (ESI) is a standard for full page caching that has a clever approach to the problem of multi step caching. It allows storing different parts of a page as different cache entries in such a way that they can even have different cache lifetimes and dynamic invalidation without affecting each other.

The upcoming Shopware 6.7 moves from a single-step full page cache to using ESI for header and footer navigation, serving as an interesting real-world experiment to observe the benefits.

Single-Step Full Page Caching

Traditionally, with a full page cache, the complete HTML Output is either cached or not cached at the time of a new request coming in:

In the case of a cache miss, database and external systems such as Elasticsearch are queried to generate the response dynamically.

The output is then cached and on the next request to that same product page, most database, and external system calls as well as all processing of the data to HTML is skipped.

This usually leads to a huge performance improvement as well as a conscious use of processing resources.

In e-commerce applications, frequent changes in stock, prices, or dynamic features like segmentation often require invalidating the cache for product and category pages – leading to a low cache hit rate and frequent full page regeneration.

Generally, there are three solutions to improve this situation:

1. Put in effort to reduce the number of cache invalidations, and the number of different cache entries due to customer segmentation. This is usually the most technically challenging approach because it requires in-depth understanding of the concrete requirements of the shop application you are optimizing.
2. Warmup the cache using a background process. Whenever an entry gets invalidated, notify a background process that regenerates this page into the cache. This effectively offloads the burden of the “slow page” to affect only a robot, not a real user. But it requires plenty of computational resources to pull off, and will come at the wasteful cost of generating a lot of cached pages that are never looked at by a real user.
3. Accept the low page cache ratio, and substantially reduce the response time for uncached pages. There is an even more radical approach here, where you build the shop application specifically with performance of product and category pages in mind, so that no caching is required at all.

Before you do all that, there are some simple first steps when trying to reduce the response time for cached pages that even a generic shop framework like Shopware (or Magento, WooCommerce for that matter) could implement first.

With multi-step caching, you can reduce the time to generate the uncached page by re-using HTML for common parts across all pages.

Conceptually, every web page can be grouped into different sections that show different high-level or detailed content of the site. The four main sections are usually header, sidebar, main content and footer.

The frontend.header route maps to a new controller action NavigationController::header:

And the actual performance gain is then visible from a code-perspective in the diff for GenericPageLoader::load where all the code for loading and rendering the navigation was removed. When header and footer are cached, then all this processing is skipped because HeaderLoader::load and FooterLoader::load are not called anymore.

Measuring the Performance Impact

Looking at the upcoming Shopware change to its full page cache, we can compare the performance impact for a demo application to get a rough gauge for real-world impact.

Comparing two aggregated traces with callgraph data for 100 profiling traces on uncached product pages with Shopware 6.6 and 6.7 we can see a 110ms improvement for our demo shop: 65,3ms saved not rendering the navigation Twig template and 45.7ms loading and processing the category and navigation data from the database.

You can access this trace comparison directly in Tideways

This is a significant improvement that will directly benefit all Shopware shops. Using ESI for header and footer is a simple and safe way to make full page caching more effective and I am keen to see the impact this change has on our Shopware benchmark report over the next quarters when people upgrade to version 6.7 of Shopware.

For you readers not using Shopware, this should hopefully serve as a good starting point on how to implement a full-page cache with muilti-step rendering to get a better overall cache hit ratio and faster responses for partially uncached pages.

Regular expressions are usually not top of mind when you think of performance bottlenecks in your application, but inefficient patterns or sub-optimal use of the APIs can make them slow.

A wonderful learning opportunity for this is a recent roughly factor of 2x performance improvement patch to Doctrine DBAL’s SQL Parser. This patch was submitted by Soner from Shopware fame, thank you to him.

Doctrine DBAL uses the SQL Parser to expand a single prepared statement parameter to a list of values, for example for a WHERE id IN (?) query.

SQL Parser Before the Patch

Before version 3.10 of Doctrine DBAL, the SQL parser used to iterate over 4 different regular expressions, and when one of them matched, the corresponding code was called. This was coded as an array of regular expression mapping to a closure:

These patterns where checked in a loop and whenever one of them matched, they were iterated over again from the beginning:

In a callgraph we can see that for 12 calls to Parser::parse, we have hundreds of calls to preg_match, key, current, next and reset and closures. Tideways has custom instrumentation for preg_match calls and shows a few starting characters of each regular expression, so that you can identify their performance individually.

A lot of potential for improvement there that this pull request captured.

The Patch

The patch rewrites the four regular expressions into a single one, using named capture groups to differentiate which one was matched:

The syntax ?P<name> creates a named capture group that is then available in the $matches result array as a key. Its an empty string if it did not match, and a non-empty string if it matched.

This change removes the layer of indirection with the closures that call methods on the Visitor and cuts down on function calls for array traversal next, key, current and reset.

Measuring the Impact: 1,7x to 2,43x faster

When benchmarking the test-script from the PR with hyperfine the results speak for themselves, an improvement by a factor of 2,43x:

And comparing two callgraph profiles from before and after the change, we also see a 10ms drop from 24ms for an improvement by a factor of 1,7x.

You can also see how the closure calls and individual preg_match‘s are replaced by the single call to preg_match in the comparison of child functions.

The individual improvement depends on how often Parser::parse is called and how long the individual queries are that are parsed. The more characters a query has, the more significant the improvement becomes.

Combining regular expressions into one big expression is a common performance improvement, and libraries such as nikic/fastroute, symfony/routing or JayBizzle/crawler-detect make good use of it as well.

PHP 8.4 includes a rather technical RFC called “Lazy Objects” which adds lazy loading functionality directly into PHP’s object model.

 In this blog post, I am going to explain what lazy loading is and how Doctrine implements it. I will show the approach the ORM took before PHP 8.4 and how the new Lazy Objects RFC improved the implementation.

By the end of the post, you will have some ideas on how to leverage this new feature for performance gains in your own application.

What is Lazy Loading?

Lazy loading is a pattern in programming that leaves the code to believe it interacts with an object of a certain type, however that object has not been fully initialized yet.

Think of lazy loading as deferring the constructor/factory of an object to a point where it’s actually used.

This allows passing around an object as a placeholder through the code, when you don’t know up front if it’s going to be used at all.

The most common example for this are database or cache connection objects, for example the connection in Doctrine DBAL:

It connects to the database using a driver once, only when used for the first time, for example in executeStatement. Many other methods also call connect to obtain the connection, which will either open it – if called the first time – or return the already open connection.

Lazy Loading in Doctrine ORM

Doctrine ORM maps database rows to PHP classes. Database tables have relationships, that Doctrine represents as references between objects.

And this is where lazy loading comes into play. With a simple example, like Post on a message board, referencing the User that posted, it is modeled as a reference:

When you want to create a list of Post objects from the database, Doctrine doesn’t want to immediately load all associated authors for performance reasons.

Because Doctrine keeps data objects free from direct dependencies on the ORM library, it’s not possible to use an abstract base class that Post and User have to extend from to implement lazy loading.

Lazy Loading with PHP Engine Hacks and Code Generation

Up until PHP 8.4, Doctrine used code generation to implement lazy loading, by using a clever combination of engine level hacks and code generation.

1. Generate a class UserProxy that extends User. Instantiate Post::$author with a UserProxy instead of a User object.
2. unset() the declared properties of an object in the constructor of the proxy
3. Implement a magic method __get interceptor that gets called when unset property is accessed, in our example User::$name
4. Load all properties of the entity from the database and set the previously unset properties with their actual values.

The generated code for the proxy would roughly look like this (this is simplified for readability):

There is a lot more nuance to it that I want to spare you from, but if you wish to dive even deeper, feel free to look at LazyGhostTrait in Symfony VarExporter and Doctrine ProxyFactory using it.

There are a few downsides to this approach:

• It requires a lot of complex code to get to work, relying on a few engine level hacks.
• It prevents users from doing certain things with their classes (can’t be final, for example)
• It can lead to weird behavior in meta programming, get_class($proxy) would not return User for example
• It requires a “compile step” and decisions when and where to place the generated proxy code in your production setup.

Lazy Loading with PHP 8.4

Lazy Loading becomes a core level feature in PHP 8.4, and you can create a lazy instance of an object through ReflectionClass::newLazyGhost now.

A lazy ghost is initialized when one of these things happens: lazy property read/write, ReflectionProperty::set(Raw)Value/get(Raw)Value and a few more.

Creating a proxy in Doctrine ORM 3.4 is just a few lines and requires no code-generation anymore:

It creates a lazy ghost with an initializer that calls EntityPersister::loadById to fetch from the database and load all values into the proxy object.

The identifier properties of the object are already set to their known values. This way, accessing them does not trigger the initialization of the object.

In the following example, the User of the Post is only loaded when User::$name is accessed:

How cool is that?

The best part is going to be, that as a next step Doctrine can implement partial objects in a way that they can load the rest of the properties when they are accessed. This will unlock marking properties as lazy, for example very large binary or content objects (blobs, clobs) that should not be loaded with an entity automatically.

By default PHPs maximum execution time is set to 30 seconds of CPU time. Since your webserver has a maximum limit of requests it can handle in parallel, this leads to an interesting question or performance and webserver throughput.

Is the maximum execution time of 30 seconds too large or too small?

In general: Yes, we recommend to decrease max_execution_time to the range of 5 or 10 seconds. But like so often, there is no one size fits all solution.

Why does everyone lean to increase max_execution_time though? If you search for this configuration on Google and YouTube you find posts that discuss exclusively how to increase it without talking about the implications.

The use-case is often that a single page starts to run into the execution time limit and the easiest option is to increase the global limit across all PHP processes and pages: Its just a quick configuration change after all.

If your webserver is near its limit of concurrent requests, a script taking 30 seconds can block 300 fast requests that only take 100ms and lead to HTTP 503 errors sent from the webserver or queueing delays. The available throughput per minute decreases massively for your given amount of PHP processes if you allow long requests.

Impact of Slow Requests on Throughput

The following example shows the throughput difference for a hypothetical PHP setup with 3 parallel processes:

In the worst case a stampede of users accessing slow parts of your site clogs up the available PHP processes and other users get served with HTTP 503 Service unavailable errors.

These conflicting scenarios show that a differentiated view is propably the best approach by configuring the max_execution_time differently for different endpoints and request types.

Strategies to safely allow high max execution time scripts

There are a few strategies to address the competing constraints of decreasing the max_execution_time in general, and allowing some scripts to have longer run times.

1. Set max_execution_time just for a single or few pages.
2. Use multiple PHP-FPM pools with different configurations
3. Implement a waiting list or a locking mechanism that restricts slow scripts to run at most once in parallel.
4. Offload slow work to a message queue

Programmatic Configuration based on Request

The max_execution_time INI setting can be changed at PHP runtime, so it makes sense to have a central place in your code-base that determines its value based on the request data (URL, method, for example):

<?php
// Symfony Http Foundation based example, also possible through $_SERVER
use Symfony\Component\HttpFoundation\Request;

$request = Request::createFromGlobals();

ini_set('max_execution_time', 5);

if ($request->getMethod() === 'POST') {
    ini_set('max_execution_time', 10);
}
if (str_starts_with($request->getPathInfo(), '/admin')) {
    ini_set('max_execution_time', 15);
}

Example: max_execution_time on Tideways app

We recently came across this problem in Tideways, where a small number of relatively unimportant reporting requests jammed the many important short API endpoints that accept data.

So there is no single perfect value, instead we solved this problem by applying the following heuristics when configuring our execution timeouts:

1. Read requests (GET, HEAD) now have a lower default timeout, because they usually don’t cause inconsistencies when they are aborted by a timeout fatal error and usually make up a large amount of the apps traffic.
2. Write requests (POST, ..) default to a higher timeout, to avoid inconsistencies when the request is aborted during the execeution.
3. We measured the latency of all endpoints, especially 95%, 99% percentiles, the maximum duration and the number of requests to get a feeling for what the best default values could be. Tideways itself collects these values over larger timespans and per endpoint.
4. We increased the timeout for endpoints that can take longer than the default timeout as long as they are low traffic endpoints. Otherwise we need to optimize their performance.
5. We decreased the timeout for endpoints that are fast, but have a very high share of requests. These requests could quickly jam the webserver resources when their performance decreases.

These are pretty basic heuristics. There are more sophisticated solutions when you need to handle more complex timeouting cases that:

1. If you have requests that are often slow and are still executed in high numbers, then consider executing them in their own PHP FPM pool with their own max number of parallel requests. This way they don’t affect other requests when requested in high numbers.
2. If you have endpoints that could write inconsistent data, but you want to limit their execution time to a low timeout anyways, consider writing your own timeout logic to have full control about potential cleanup.
3. Often slowness is caused by external services (HTTP) or databases (MySQL), in which case we would solve the problem by specifying client side timeouts that can be gracefully handled.

I will write about each of them individually in the next weeks. If you are interested make sure to sign up for the newsletter to get updated when the posts are published.

Every so often, a careful profiling analysis of your application detects the bottleneck in third-party code and there is little remedy for you to override or change that code. In this blog post I want to present a solution to fixing performance problems in third-party libraries by using the composer patches plugin.

I use the the Symfony ErrorHandler as an example. Another example could be patching a performance bottleneck in Doctrine DBAL array parameter processing for an older version with the code from a newer version.

For certain applications that frequently trigger Symfony deprecations, this may result in a significant loss of response time, because it treats deprecations as a “strong error” that should not be silenced. For instance, in this Tideways trace from a Shopware store, a total of 18794 deprecations result in an additional response time of 699 ms:

An obvious first step would be to fix the code that triggers the deprecations, but here the Shopware core is triggering this deprecation itself. Shopware core is third party code that we cannot just change, especially when installed via Composer. The original code is installed over our changes on every Composer installation or update.

An issue to request a change in this policy to treat deprecations as errors that can never be silenced has been open for a while now. As usual, it’s not as easy for the developers of a framework to find a generic solution that works for them and everyone. 

We can intervene here by using the excellent cweagans/composer-patches library, which allows patching vendor code as a subsequent step after installing or updating dependencies. Install the library into your project: composer require cweagans/composer-patches:2.0.0-beta2

Then we create a new file “patches/symfony_error_handler.patch” and add the following patch for symfony/error-handler:

I would always store the patch locally and avoid using the remote patch feature of this plugin for security reasons.

And modify the composer.json to include a reference to this patch like this:

After this change, you can apply the patch by calling “composer patches-repatch”:

From this point forward, the patch will be applied during every composer installation or update if the error-handler package changes.

Please be aware that this change effectively disables Symfony deprecation functionality unless the Symfony application is in debug mode.