理解和实现用于框架和理论的Symfony 3缓存

Question

我们有一个运行中的应用程序，它基于Symfony 3.2 (从Symfony 2.3开始)和DoctrineORM2.5。

我读了很多关于新的Symfony Cache组件，APC和APCU的上下部分，opcache，在Symfony中进行聊天的拉请求等等。但老实说这次你有点失去我了。

因此，我善意地问，人们是否能够支持我理解和2)在生产中为“标准”Symfony/Doctrine应用程序实现缓存。

Prerequisites/Assumptions

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);

根据我的理解，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();

2)验证缓存

我们的config_prod.yml里还有这个

framework:
validation:
    cache: validator.mapping.cache.doctrine.apc

问题：

老实说，我不知道这在Symfony 3.2和新的Cache组件中是否仍然有效。以及如何在需要时将其更改为不同的缓存提供程序。我怎么能用Symfony 3.2缓存把它修改成“最新的”呢？

3)原则缓存：

同样的问题或多或少也适用于config_prod.yml中的学说部分。

doctrine:
orm:
    metadata_cache_driver: apc
    result_cache_driver: apc
    query_cache_driver: apc

问题

这还是要走的路吗？如何改变这个使用新的Symfony缓存组件--这无论如何都能做到吗？

4)新选项？

那新的呢？有选择吗？在config_prod.yml中设置

framework:
cache:
    app: cache.adapter.someProviderOrPool
    system: cache.adapter.someProviderOrPool

问题

这里缓存的是什么样的信息，这是由谁以某种方式取代/扩展了上面的一些主题？

来总结它：

我想从根本上改变我所有的建议，使之符合Symfony 3.2，我想尽可能地使用redis进行缓存(替换apc)，但我完全不知道如何和从何处开始。

编辑*

在这种情况下，Symfony组件和DoctrineCacheBundle是如何协同工作的呢？替换？加起来？在此基础上？一起工作？互相冲突？没有可比性？

Answer 1

编辑:从那以后，这里写的所有东西都被合并到Symfony的官方文档中。https://symfony.com/doc/current/performance.html

使用OPcache字节码缓存

OPcache存储已编译的PHP文件，以避免对每个请求重新编译它们。有一些字节码缓存可用，但从PHP5.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

不检查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

Note

对于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

配置PHP缓存

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

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

; php.ini

realpath_cache_size=4096K
realpath_cache_ttl=600

优化作曲家Autoloader

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

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

$ composer install --no-dev --optimize-autoloader --classmap-authoritative --apcu-autoloader

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

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

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

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

Tip

如果生产服务器仍然使用遗留的APC扩展而不是OPcache，请在应用程序中安装APCu填充组件，以便与APCu PHP函数兼容，并解锁对高级Symfony特性(如APCu缓存适配器)的支持。

Note

在使用APCu自动加载程序时，如果您添加了新的类，它们将被自动找到，并且所有的东西都会像以前一样工作(即没有理由“清除”缓存)。但是，如果更改特定名称空间或前缀的位置，则需要刷新APCu缓存。否则，自动加载程序仍将查看名称空间中所有类的旧位置。