PerformanceEdit this page
Warning: You are browsing the documentation for Symfony 5.0, which is no longer maintained.
Read the updated version of this page for Symfony 6.2 (the current stable version).
- Symfony Application Checklist
- Production Server Checklist
- Learn more
Symfony is fast, right out of the box. However, you can make it faster if you optimize your servers and your applications as explained in the following performance checklists.
These are the code and configuration changes that you can make in your Symfony application to improve its performance:
If your production server still uses the legacy APC PHP extension instead of OPcache, install the APCu Polyfill component in your application to enable compatibility with APCu PHP functions and unlock support for advanced Symfony features, such as the APCu Cache adapter.
Symfony compiles the service container into multiple
small files by default. Set this parameter to
true to compile the entire
container into a single file, which could improve performance when using
"class preloading" in PHP 7.4 or newer versions:
1 2 3 4
# config/services.yaml parameters: # ... container.dumper.inline_factories: true
1 2 3 4 5 6 7 8 9 10 11
<!-- config/services.xml --> <container xmlns="http://symfony.com/schema/dic/services" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://symfony.com/schema/dic/services https://symfony.com/schema/dic/services/services-1.0.xsd"> <parameters> <!-- ... --> <parameter key="container.dumper.inline_factories">true</parameter> </parameters> </container>
1 2 3 4
// config/services.php // ... $container->setParameter('container.dumper.inline_factories', true);
These are the changes that you can make in your production server to improve performance when running Symfony applications:
- Use the OPcache byte code cache
- Use the OPcache class preloading
- Configure OPcache for maximum performance
- Don't check PHP files timestamps
- Configure the PHP realpath Cache
- Optimize Composer Autoloader
OPcache stores the compiled PHP files to avoid having to recompile them for every request. There are some byte code caches available, but as of PHP 5.5, PHP comes with OPcache built-in. For older versions, the most widely used byte code cache is APC.
Starting from PHP 7.4, OPcache can compile and load classes at start-up and make them available to all requests until the server is restarted, improving performance significantly.
During container compilation, Symfony generates the file with the list of
classes to preload. The only requirement is that you need to set both
The preload file path is the same as the compiled service container but with the
; php.ini opcache.preload=/path/to/project/var/cache/prod/srcApp_KernelProdContainer.preload.php
The default OPcache configuration is not suited for Symfony applications, so it's recommended to change these settings as follows:
1 2 3 4 5 6
; php.ini ; maximum memory that OPcache can use to store compiled PHP files opcache.memory_consumption=256 ; maximum number of files that can be stored in the cache opcache.max_accelerated_files=20000
In production servers, PHP files should never change, unless a new application version is deployed. However, by default OPcache checks if cached files have changed their contents since they were cached. This check introduces some overhead that can be avoided as follows:
; php.ini opcache.validate_timestamps=0
After each deploy, you must empty and regenerate the cache of OPcache. Otherwise you won't see the updates made in the application. Given that in PHP, the CLI and the web processes don't share the same OPcache, you cannot clear the web server OPcache by executing some command in your terminal. These are some of the possible solutions:
- Restart the web server;
- Call the
opcache_reset()functions via the web server (i.e. by having these in a script that you execute over the web);
- Use the cachetool utility to control APC and OPcache from the CLI.
When a relative path is transformed into its real and absolute path, PHP caches the result to improve performance. Applications that open many PHP files, such as Symfony projects, should use at least these values:
1 2 3 4 5 6
; php.ini ; maximum memory allocated to store the results realpath_cache_size=4096K ; save the results for 10 minutes (600 seconds) realpath_cache_ttl=600
PHP disables the
realpath cache when the open_basedir config option
The class loader used while developing the application is optimized to find
new and changed classes. In production servers, PHP files should never change,
unless a new application version is deployed. That's why you can optimize
Composer's autoloader to scan the entire application once and build a "class map",
which is a big array of the locations of all the classes and it's stored
Execute this command to generate the class map (and make it part of your deployment process too):
$ composer dump-autoload --no-dev --classmap-authoritative
--no-devexcludes the classes that are only needed in the development environment (i.e.
--classmap-authoritativecreates a class map for PSR-0 and PSR-4 compatible classes used in your application and prevents Composer from scanning the file system for classes that are not found in the class map. (see: Composer's autoloader optimization).