Opcache: Difference between revisions

Latest revision as of 12:25, 19 March 2018

Is your Zend Opcache out of memory? Do you see "Warning Interned string buffer overflow" in Apache's error log? We've tweaked the Opcache settings for better performance.

Meza installs php56u-opcache in /opt/meza/src/roles/apache-php/tasks/php.yml and sets opcache.interned_strings_buffer=4 in /opt/meza/src/roles/apache-php/templates/php.ini.j2

In raising the setting we also optimized the PHP opcache according to the Scaling PHP book recommendations.

Also, in order to effectively monitor our actual usage of the Opcache, I installed Rasmus Ledorf's (creator of PHP): opcache-status for instances where the deploy mode is 'development'. Note: There are a few (simple+good) pull requests that have sat idle for a long time, so it might be better to use a fork, or create a fork instead of using Rasmus' repo.

Opcache status does reveal document root and physical script path information so it's best to keep it 'private' (hence why we only install it in development). I've left out details on installation (see example). Apache configuration to restrict access to opcache.php.

Opcache.max_accelerated_files should be larger than the number of files in your project. We have ~7455, ^[1] and the next prime number is 7963. So let's set it to 7963 (currently 20,000)

One big change recommended by the book is to never re-validate file timestamps in production...it's wasting valuable time with stat calls. Instead, the book says re-validate in the dev environment, and whenever you push to production, restart your webserver.

"Yes, this is a pain in the ass, but you should use it. Why? While you're updating or deploying code, new code files can get mixed with old ones— the results are unknown. It's unsafe as hell."

TL;DR-

in php.ini

opcache.revalidate_freq=0
opcache.validate_timestamps=0 (set to 1 in dev environments)
opcache.max_accelerated_files=7963
opcache.memory_consumption=256 (unchanged from current)
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1

↑

cd /opt/htdocs
find . -type f -print | grep php | wc -l
7455

[1] 
cd /opt/htdocs find . -type f -print | grep php | wc -l 7455

[1]

@@ Line 3: / Line 3: @@
 Meza installs <code>php56u-opcache</code> in <code>/opt/meza/src/roles/apache-php/tasks/php.yml</code> and sets <code>opcache.interned_strings_buffer=4</code> in /opt/meza/src/roles/apache-php/templates/php.ini.j2</code>
-In raising the setting we also optimized the PHP opcache according to the '''Scaling PHP''' book recommendations.
+In raising the setting we also optimized the PHP opcache according to the '''[https://www.scalingphpbook.com/blog/2014/02/14/best-zend-opcache-settings.html Scaling PHP]''' book recommendations.
-Also, in order to effectively monitor our actual usage of the Opcache, I installed Rasmus Ledorf's (creator of PHP): https://github.com/rlerdorf/opcache-status.git for instances where the deploy mode is 'development'. Note: There are a few (simple+good) pull requests that have sat idle for a long time, so it might be better to use a fork, or create a fork instead of using Rasmus' repo.
+Also, in order to effectively monitor our actual usage of the Opcache, I installed Rasmus Ledorf's (creator of PHP): [https://github.com/rlerdorf/opcache-status.git opcache-status] for instances where the deploy mode is 'development'. Note: There are a few (simple+good) pull requests that have sat idle for a long time, so it might be better to use a fork, or create a fork instead of using Rasmus' repo.
-Opcache status does reveal document root and physical script path information so it's best to keep it 'private' (hence why we only install it in development). I've left out details on installation e.g. and Apache configuration to restrict access to opcache.php.
+Opcache status does reveal document root and physical script path information so it's best to keep it 'private' (hence why we only install it in development). I've left out details on installation ([https://github.com/rlerdorf/opcache-status/pull/50/files see example]). Apache configuration to restrict access to opcache.php.
 <code>Opcache.max_accelerated_files</code> should be larger than the number of files in your project. We have ~7455, <ref>
@@ Line 17: / Line 17: @@
 </ref> and the next prime number is 7963. So let's set it to 7963 (currently 20,000)
-One big change recommended by the book is to never re-validate file timestamps in production...it's wasting valuable time with stat calls. Instead, the book says re-validate in the dev environment, and whenever you push to production, restart your webserver.
+One big change recommended by the book is to never re-validate file timestamps in production...it's wasting valuable time with stat calls. Instead, the book says re-validate in the dev environment, and whenever you push to production, [https://www.cyberciti.biz/faq/unix-linux-restart-php-service-command/ restart your webserver].
 <blockquote>
 "Yes, this is a pain in the ass, but you should use it. Why? While you're updating or deploying code, new code files can get mixed with old ones— the results are unknown. It's unsafe as hell."