enterprisemediawiki / meza

Setup an enterprise MediaWiki server with simple commands
MIT License
41 stars 27 forks source link

Optimize PHP Opcache #941

Open freephile opened 6 years ago

freephile commented 6 years ago

Is your Zend Opcache out of memory? Do you see "Warning Interned string buffer overflow" in Apache's error log as mentioned here? Meza should optimize/tweak 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

I propose raising the setting and also optimizing the PHP opcache according to the Scaling PHP book recommendations.

Also, in order to effectively monitor your actual usage of the Opcache, I propose installing another file by Rasmus Ledorf (creator of PHP): https://github.com/rlerdorf/opcache-status.git This could go into the ServerPerformance directory, document root, or elsewhere. Opcache status does reveal document root and physical script path information so perhaps it needs to be 'private'? I've left out details on installation e.g. and Apache configuration to restrict access to opcache.php. 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.

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

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

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 whenver you push to production, send a kill -SIGUSR2 to the PHP process (aka restart your webserver).

"Yes, this is a pain in the ass, but you should use it. Why? While you're updating or deplying 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 (comment this out in your dev environment)
opcache.max_accelerated_files=7963
opcache.memory_consumption=256 (unchanged from current)
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1

Environment

You can look at my current environment using Rasmus' opcache.php file. https://demo.qualitybox.us/ServerPerformance/opcache-status/opcache.php

freephile commented 6 years ago

Note: Rasmus' repo version uses jquery 1.11.0 and d3 3.0.1 Those should probably be upgraded and tested for compatibility (or it's an extra reason to hide the scripts from anyone who's not an admin on the server).

Note 2: Rasmus loads his JavaScript from cloudflare. Another reason to use or make a fork that loads them locally.

jamesmontalvo3 commented 6 years ago

So it sounds like one thing you're recommending is simple config changes. Go ahead and PR that. Other changes may be more controversial config changes. Perhaps those should be separate PR(s).

Quality box link fails. I'm not sure how javascript and opcache are related.

freephile commented 6 years ago

I'm generating a new PR, from a different branch since this one is spelled wrong.

The javascript is used in the opcache.php script; so a different matter than straight configuration changes.