performance


Symfony is extremely fast. Of course, if you really need speed, there are many ways you can make Symfony faster. In this chapter, you'll explore some ways to speed up your Symfony programs.

Use Byte Code Cache (such as OPcache)

The first thing you should do when improving performance is to use a "byte code cache". These caches store compiled PHP files to avoid compiling them again on every request.

There are many byte code caches available, some of which are open source. As of PHP 5.5, PHP has built-in OPcache. The most widely used byte code cache in older versions is APC.

Using byte code cache has all the advantages and disadvantages, and Symfony is built to "perform extremely well in this type of environment."

Monitor changes in source files

Most byte code caches monitor changes in source files. This ensures that if the file source code changes, the byte code will be automatically compiled. This is very convenient, but a bit overloaded.

Therefore, some byte code caches provide an option to turn off these checks. For example, to turn off checking in APC, add apc.stat=0 directly to your php.ini configuration file.

When these checks are turned off, it is the server administrator's responsibility to "ensure that the cache is cleared when any source files are changed." Otherwise, your updates will not be visible in the program.

Similarly, the byte code cache must be cleared when deploying the program (for example, when using APC, by calling the apc_clear_cache() PHP function, and when using Opcache, by calling opcache_reset( )).

In PHP, the command line and web process do not share the same OPcache. This means that you cannot clear the OPcache on the web server by executing certain commands in the terminal. You can restart the server or call the apc_clear_cache() or opcache_reset() function through the web server (for example, to include them when executing web scripts).

Optimize all files used by Symfony

By default, PHP's OPcache stores 2000 files in the byte code cache. This number is still too small for normal Symfony applications, so you must set the opcache.max_accelerated_files configuration option to a higher value: 

; php.iniopcache.max_accelerated_files = 20000

Configure PHP realpath cache

PHP uses an internal cache to store the result of mapping the "class file path" to the "real file system path". This improves the performance of programs like Symfony that open many PHP files, especially on Windows platforms.

By default, PHP sets a 16K realpath_cache_size, which is too small for Symfony. Update this value to at least 4096K. In addition, the cache path is only saved for 120 seconds by default. Also consider updating this value through the realpath_cache_ttl option: 

; php.ini
realpath_cache_size=4096K
realpath_cache_ttl=600

Use Composer's class mapping function

By default, Symfony Standard Edition uses the Composer autoloader (autoloader) in the autoload.php file. This loader is easy to use because it automatically looks for any new classes you place in the registered directory.

Unfortunately, this has a cost, as the class loader has to traverse the entire configured namespace in order to find a specific file, making file_exists() calls until it finally finds it to the desired file.

The simplest solution is to tell Composer to build an optimized "class map" (class map), which is a large array of the locations of all classes and is stored in vendor/composer/autoload_classmap. php in.

This class map can be generated from the command line and may become part of your deployment process.

  • --optimize
  • Strip every PSR-0 and PSR-4 compatible class in your program.
  • --no-dev
  • Exclude classes that you only use in the development environment (such as tests).
  • --classmap-authoritative
  • Prevents Composer from looking for classes in the file system that do not appear in the class map.

Cache Autoloader with APC

Another solution is to cache the location of the class after it is first located. Symfony comes with a class - ApcClassLoader - specifically used for this. To use it, just adapt your front controller file. If you are using the standard version of the framework, you can make the following changes:

// app.php// ... 
use Symfony\Component\ClassLoader\ApcClassLoader; 
$loader = require __DIR__.'/../app/autoload.php';include_once __DIR__.'/../app/bootstrap.php.cache'; 
// Use APC for autoloading to improve performance
// Change 'sf2' by the prefix you want in order
// to prevent key conflict with another application
// 使用APC自动加载以提升性能，改变'sf2'为你希望的前缀，
// 以防止同其他程序发生key冲突$loader = new ApcClassLoader('sf2', $loader);$loader->register(true); 
// ...

For more details, refer to the Cache Class Loader article.

When using the APC autoloader, if you add new classes, they will be found automatically and everything will work as usual (i.e., there is no need to "clear" the cache). However, if you change the location of a specific namespace or prefix, you will need to flush your APC cache. Otherwise, the autoloader will still look for all classes in the old locations in that namespace.

Using Bootstrap files

To ensure flexible optimization and code reuse, Symfony programs utilize a variety of classes and third-party components. But loading all of these classes from scattered locations on every request results in a certain level of overload. To reduce the burden, Symfony provides a script to generate a file called bootstrap file, which considers loading multiple class definitions in a single file. By including this file (which contains copies of various core classes), Symfony no longer needs to include any source files that contain those classes. This will reduce a lot of hard disk throughput (disc IO).

If you are using Symfony Standard Edition, you should have used this bootstrap startup file. To ensure usage, open your front controller (usually app.php) and check that the following line of code actually exists:

##
1
$  composer dump-autoload --optimize --no-dev --classmap-authoritative
1
include_once __DIR__.'/../var/bootstrap.php.cache';

Note that there are two disadvantages when using bootstrap files:

  • This file will be regenerated when any of the original resources change (for example, when you update Symfony's src code or vendor third-party class library);
  • When debugging, developers need to set breakpoints in the bootstrap file.

If you are using the Symfony standard version, the startup file will be automatically rebuilt through the composer install command after the vendor class library is updated (Annotation: refers to composer.json The post script, etc. can also be executed manually)

Bootstrap file and Byte Code cache

Even if a byte code cache is used, the bootstrap file will still be used. Performance will be improved because fewer files need to be monitored for "changes." Of course, if this function is turned off in the byte code cache (that is, setting apc.stat=0 in APC), there will be no reason to use the bootstrap file.