问题
I have an m3.xlarge EC2 instance that I updated to PHP 5.5.11 today.
With this update, it overwrote php55-pecl-apc with php55-pecl-apcu.
After reading and experimenting, my understanding is that APC has been replaced with OPCache, except for a key value store which can be brought back with 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).
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
Right now I'm just hanging out with OPCache, and no APCu.
- 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.
- 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?
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.
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
回答1:
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):
opcache.validate_timestamps=0
Alternatively, you can try setting the frequency to something other than 0 and keep it enabled:
opcache.validate_timestamps=1
opcache.revalidate_freq=300
This should theoretically only check for changes every 5 minutes.
回答2:
You also have
opcache.consistency_checks=1
Which according to the docs says will slow down performance. Turn that off.
opcache.consistency_checks integerIf 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.
回答3:
From the RFC that was responsible for making OPCache integrated into PHP:
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.
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://stackoverflow.com/questions/23382615/apc-apcu-opcache-performance-poor