php APC -> APCu / OPCache，性能较差

APC -> APCu / OPCache, performance poor

提问by Tallboy

I have an m3.xlargeEC2 instance that I updated to PHP 5.5.11today.

我今天m3.xlarge更新了一个EC2 实例PHP 5.5.11。

With this update, it overwrote php55-pecl-apcwith php55-pecl-apcu.

在此更新中，它覆盖php55-pecl-apc了php55-pecl-apcu.

After reading and experimenting, my understanding is that APChas been replaced with OPCache, except for a key value store which can be brought back with APCu.

经过阅读和实验，我的理解是APC已经换成了OPCache，除了一个键值存储可以带回来APCu。

After tweaking my config to something that looks reasonable, using Wordpress while logged in is now terribly slow, at least 300-900ms worse (the front end is cached via varnish, and works perfect... but when you're using the admin it is deliberately not cached, and slow as sin).

在将我的配置调整为看起来合理的东西后，登录时使用 Wordpress 现在非常慢，至少 300-900 毫秒更糟（前端通过清漆缓存，并且工作完美......但是当你使用管理员时故意不缓存，慢如罪）。

I did a series of benchmarks as I upgraded, across a small sample size for each step. It degraded worse and worse as I went on.

我在升级时做了一系列基准测试，每个步骤的样本量很小。随着我的继续，它变得越来越糟。

• APC (before upgrade) -->
• OPCache + no APCu -->
• OPCache + APCu + WP Plugin for APCu

• APC（升级前） -->
• OPCache + 无 APCu -->
• APCu 的 OPCache + APCu + WP 插件

Right now I'm just hanging out with OPCache, and no APCu.

现在我只是在玩 OPCache，没有 APCu。

1. How can I achieve the same performance? I loved the admin interface, I loved how fast it was. I honestly don't see how this is an improvement at all, it's quite depressing really... unless there is some super library out there that I'm not aware of. It's certainly not what I have though, or maybe it's not configured well.
2. Assuming the answer to #1 is 'you configured it like balls', then would you mind taking a look at this and seeing if this is reasonable?

1. 我怎样才能达到同样的性能？我喜欢管理界面，我喜欢它的速度。老实说，我根本看不出这是如何改进，这真的很令人沮丧……除非有一些我不知道的超级图书馆。不过，这肯定不是我所拥有的，或者可能没有配置好。
2. 假设 #1 的答案是“你像球一样配置它”，那么你介意看看这个，看看这是否合理？

For my setup I'm using latest wordpress, a few large plugins but I can't take them off because they're important. Luckily varnish takes care of most of the work. I have 4 cores, 16GB memory, ~10k files in my website root. I also have no real hardcore apps or anything other than wordpress, it's a fairly vanilla setup. I think that's it for stuff that might help.

对于我的设置，我使用的是最新的 wordpress，一些大型插件，但我无法将它们取下，因为它们很重要。幸运的是，清漆处理了大部分工作。我的网站根目录中有 4 个内核、16GB 内存、约 10k 个文件。我也没有真正的核心应用程序或除了 wordpress 之外的任何东西，这是一个相当普通的设置。我认为这就是可能有帮助的东西。

Config:

配置：

zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.max_wasted_percentage=5
opcache.use_cwd=1
opcache.validate_timestamps=1
opcache.revalidate_freq=0
opcache.revalidate_path=0
opcache.save_comments=0
opcache.load_comments=0
opcache.fast_shutdown=1
opcache.enable_file_override=0
opcache.optimization_level=0xffffffff
opcache.inherited_hack=1
opcache.dups_fix=0
opcache.blacklist_filename=/etc/php-5.5.d/opcache*.blacklist
opcache.max_file_size=2M
opcache.consistency_checks=1
opcache.force_restart_timeout=180
opcache.error_log=/var/log/php-fpm/5.5/opcache.log
opcache.log_verbosity_level=1
opcache.preferred_memory_model=
opcache.protect_memory=0

采纳答案by knrdk

Right now you are checking every file on every request for changes, which probably isn't what you want on a production system.

现在，您正在检查每个更改请求的每个文件，这可能不是您在生产系统上想要的。

I usually just disable it (remember to restart the web server after making changes):

我通常只是禁用它（记住在进行更改后重新启动 Web 服务器）：

opcache.validate_timestamps=0

Alternatively, you can try setting the frequency to something other than 0 and keep it enabled:

或者，您可以尝试将频率设置为 0 以外的值并保持启用状态：

opcache.validate_timestamps=1  
opcache.revalidate_freq=300

This should theoretically only check for changes every 5 minutes.

这理论上应该只每 5 分钟检查一次更改。

回答by awhig

You also have

你还有

opcache.consistency_checks=1

Which according to the docs says will slow down performance. Turn that off.

根据文档说这会降低性能。把它关掉。

opcache.consistency_checks integer

If non-zero, OPcache will verify the cache checksum every N requests, where N is the value of this configuration directive. This should only be enabled when debugging, as it will impair performance.

opcache.consistency_checks integer

如果非零，OPcache 将每 N 个请求验证一次缓存校验和，其中 N 是此配置指令的值。这应该只在调试时启用，因为它会影响性能。

回答by saboya

From the RFC that was responsible for making OPCache integrated into PHP:

来自负责将 OPCache 集成到 PHP 中的 RFC：

APC can reclaim memory of old invalidated scripts. APC uses a memory manager and can reclaim memory associated with a script that is no longer in use; Optimizer+ works differently, and marks such memory as ‘dirty', but never actually reclaims it. Once the dirty percentage climbs above a configurable threshold - Optimizer+ restarts itself. Note that this behavior has both stability advantages and disadvantages.

APC 可以回收旧的无效脚本的内存。APC 使用内存管理器，可以回收与不再使用的脚本相关的内存；Optimizer+ 的工作方式不同，并将此类内存标记为“脏”，但从未真正回收它。一旦脏百分比上升到可配置的阈值以上 - Optimizer+ 会自行重新启动。请注意，这种行为既有稳定性的优点，也有缺点。

My guess is that you are hitting the threshold that triggers the opcode cache restart.

我的猜测是您正在达到触发操作码缓存重启的阈值。

Reference: https://wiki.php.net/rfc/optimizerplus#advantages_of_apc_over_optimizer

参考：https: //wiki.php.net/rfc/optimizerplus#advantages_of_apc_over_optimizer