试图理解和实现Symfony 3 Caching for Framework和Doctrine

LBA*_*LBA 10 symfony doctrine-orm

我们有一个基于Symfony 3.2(当时以Symfony 2.3开始)和Doctrine ORM 2.5的运行应用程序,它的发展方式非常棒.

我读了很多关于新的Symfony Cache组件,APC和APCU的up和down,opcache,Symfony中的chaching请求等等......但是老实说这次你失去了我一点.

所以我很想知道是否可以支持我1)理解和2)在生产中实现"标准"Symfony/Doctrine应用程序的缓存.

前提条件/假设

1)opcache应该被启用并激活并缓存任何与字节码相关的内容.

2)我目前没有任何要求缓存我自己的应用程序的东西.这些都是关于框架缓存的,如注释,类映射,验证,ORM元数据等.

2)大多数开发人员不想处理多个缓存提供程序,所以无论是APCu,xcache,redis,memcache还是其他任何东西.可能有很好的理由为不同的任务设置不同的任务,但让我们坚持一个以保持简单.

在prod模式下的"标准"Symfony/Doctrine应用程序中缓存选项

1)班级装载

我们仍然有ApcClassLoader app.php:

$loader = require __DIR__ . '/../app/autoload.php';
include_once __DIR__ . '/../var/bootstrap.php.cache';

$apcLoader = new ApcClassLoader('arcsf2', $loader);
$apcLoader->register(true);
$loader->unregister();

require_once __DIR__ . '/../app/AppCache.php';

$kernel = new AppKernel('prod', false);
$kernel->loadClassCache();
$kernel = new AppCache($kernel);
Run Code Online (Sandbox Code Playgroud)

根据我的理解,Symfony只有两个选项,ApcClassLoader和XcacheClassLoader.所以这可能与上面的假设2相矛盾.

题:

是否仍需要/需要/表现得更好才能使用这种缓存ClassLoaders?

或者现在使用标准app.php就够了吗?

$loader = require __DIR__.'/../app/autoload.php';
include_once __DIR__.'/../var/bootstrap.php.cache';

$kernel = new AppKernel('prod', false);
$kernel->loadClassCache();
Run Code Online (Sandbox Code Playgroud)

2)验证缓存

我们仍然有这个config_prod.yml:

framework:
validation:
    cache: validator.mapping.cache.doctrine.apc
Run Code Online (Sandbox Code Playgroud)

题:

老实说,我不知道这是否仍然适用于Symfony 3.2和新的Cache组件.如果需要,如何将其更改为不同的缓存提供程序.我怎么能用Symfony 3.2 Cache将它改成'最新'?

3)Doctrine Caching:

或多或少相同的问题适用于以下原则config_prod.yml:

doctrine:
orm:
    metadata_cache_driver: apc
    result_cache_driver: apc
    query_cache_driver: apc
Run Code Online (Sandbox Code Playgroud)

问题:

这仍然是要走的路吗?如何更改它使用新的Symfony Cache组件 - 无论如何都可以这样做?

4)新选项?

新的怎么样?选择?设置config_prod.yml:

framework:
cache:
    app: cache.adapter.someProviderOrPool
    system: cache.adapter.someProviderOrPool
Run Code Online (Sandbox Code Playgroud)

问题:

什么样的信息在这里被缓存,由谁以及以某种方式取代/扩展上述一些主题?

把它们加起来:

我想基本上改变我所有的prod配置,以便与Symfony 3.2兼容,我想尽可能使用redis进行缓存(替换apc),但我完全不知道如何以及从何处开始.

****编辑****

在这种情况下,Symfony Cache Component和DoctrineCacheBundle如何一起玩?更换?加起来?建设?一起工作?冲突?不可比?

Erd*_* G. 4

编辑:从那时起,这里编写的所有内容都已合并到 Symfony 的官方文档中。您可能想查看最新的文档

使用OPcache字节码缓存

OPcache 存储已编译的 PHP 文件,以避免为每个请求重新编译它们。有一些可用的字节码缓存,但从 PHP 5.5 开始,PHP 内置了 OPcache。对于旧版本,使用最广泛的字节码缓存是APC。

配置 OPcache 以获得最佳性能

默认的 OPcache 配置不适合 Symfony 应用程序,因此建议按如下方式更改这些设置:

; php.ini

; maximum memory that OPcache can use to store compiled PHP files
opcache.memory_consumption=256M

; maximum number of files that can be stored in the cache
opcache.max_accelerated_files=20000
Run Code Online (Sandbox Code Playgroud)

不检查 PHP 时间戳

在生产服务器中,PHP 文件永远不应更改,除非部署新的应用程序版本。但是,默认情况下,OPcache 会检查缓存文件自缓存以来是否已更改其内容。此检查会引入一些可以避免的开销,如下所示:

; php.ini

; after each deploy, call `opcache_reset()` or restart the web server
; to empty the cache and regenerate the cached files. Otherwise you won't
; see the updates made in the application
opcache.validate_timestamps=0
Run Code Online (Sandbox Code Playgroud)

笔记

Web 服务器和命令控制台的 OPcache 是不同的。您无法通过在终端中执行某些命令来清除 Web 服务器 OPcache。您需要重新启动 Web 服务器或通过 Web 服务器调用 opcache_reset() 函数(即,将其放在通过 Web 执行的脚本中)。

配置 PHP 真实路径缓存

当相对路径转换为真实的绝对路径时,PHP 会缓存结果以提高性能。此缓存的默认配置不适合打开许多 PHP 文件的应用程序,例如 Symfony。建议按如下方式更改这些设置:

; 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
Run Code Online (Sandbox Code Playgroud)

配置 PHP 真实路径缓存

PHP 使用内部缓存来存储将文件路径映射到其真实和绝对文件系统路径的结果。这提高了 Symfony 等打开许多 PHP 文件的应用程序的性能,尤其是在 Windows 系统上。

默认情况下,PHP 将 realpath_cache_size 设置为 16K,这对于 Symfony 来说太低了。请考虑将此值至少更新为 4096K。此外,缓存路径默认仅存储 120 秒。也考虑使用以下realpath_cache_ttl选项更新此值:

; php.ini

realpath_cache_size=4096K
realpath_cache_ttl=600
Run Code Online (Sandbox Code Playgroud)

优化 Composer 自动加载器

开发应用程序时使用的类加载器经过优化,可以查找新的和更改的类。在生产服务器中,PHP 文件永远不应更改,除非部署新的应用程序版本。这就是为什么您可以使用 Composer 的自动加载器优化来扫描整个应用程序一次并构建一个“类映射”,它是所有类的位置的一个大数组,并且存储在vendor/composer/autoload_classmap.php中。

执行此命令以在安装时生成类映射(从而使其成为部署过程的一部分):

$ composer install --no-dev --optimize-autoloader --classmap-authoritative --apcu-autoloader
Run Code Online (Sandbox Code Playgroud)

--no-dev排除仅在开发环境中需要的类(例如测试)。

--optimize-autoloader转储应用程序中使用的每个 PSR-0 和 PSR-4 兼容类。

--classmap-authoritative防止 Composer 扫描文件系统以查找类映射中未找到的类。

--apcu-autoloader您需要安装 APCu PHP 扩展才能使用此选项。它将在 APCu 中缓存类映射。但它不会生成类映射,因此您需要始终将它与--optimize-autoloader

提示

如果您的生产服务器仍然使用旧版 APC PHP 扩展而不是 OPcache,请在应用程序中安装 APCu Polyfill 组件,以启用与 APCu PHP 功能的兼容性并解锁对高级 Symfony 功能(例如 APCu 缓存适配器)的支持。

笔记

使用 APCu 自动加载器时,如果添加新类,它们将被自动找到,并且一切都将像以前一样工作(即没有理由“清除”缓存)。但是,如果更改特定命名空间或前缀的位置,则需要刷新 APCu 缓存。否则,自动加载器仍将查找该命名空间内所有类的旧位置。