Feature optimize opcache

[freephile]

Changes to the php.ini to optimize PHP's Opcache

Introduces new config called 'm_mode' (default 'production').
meza mode (development or production)

1. production being as performant and secure as possible
2. development being less secure and providing optional features useful for dev

[freephile]

I documented 'Opcache' at https://meta.qualitybox.us/wiki/Opcache

[jamesmontalvo3]

Regarding opcache.validate_timestamps...how does this work with meza deploy? How will deploy know when it has to restart httpd?

[freephile]

Well, the only PHP files would theoretically be local extensions, core extensions, or core updates (and a few miscellaneous like ServerPerformance, WikiBlender). I think Apache gets restarted on the 'mediawiki' role....checking.... nope there isn't a handler.

OK, so we should have a handler that can stop Apache (or at least put the wiki into read-only with a site notice) and then do the mediawiki role, and then start or reload Apache. That would perhaps require a new setup in HAProxy or Apache that could serve a static file during deploys.

[jamesmontalvo3]

Taking the site down or substantially limiting it seems like a heavy handed approach. Also I wasn't under the impression that Apache needed to stop during deploy...just that after a file-changing deploy it'd need to be restarted. How hard would it be to detect if anything changed in /opt/htdocs during deploy, and if so then restart httpd?

[jamesmontalvo3]

opcache.max_accelerated_files=7963

You chose this number based on the number of PHP files in /opt/htdocs and /opt/.deploy-meza I assume? What if an install has a substantial number of large extensions? By default we may want to make this larger...with plenty of room to add extensions, but could make the value configurable via public.yml for systems that want to dial in the efficiency.

[jamesmontalvo3]

m_mode seems a little vague. How about m_environment_purpose or something like that? e.g. "what's the purpose of this environment? Production."

[jamesmontalvo3]

Rather than restart Apache, I think we could just reset opcache by doing the following:

1. Create /opt/htdocs/flush-cache.php with contents

<?php

if ( 
	! isset( $_SERVER['HTTP_X_FORWARDED_FOR'] ) && 
	( $_SERVER['REMOTE_ADDR'] === 'localhost' || $_SERVER['REMOTE_ADDR'] === '127.0.0.1' ) 
) {
	opcache_reset();
}
else {
	header('HTTP/1.0 403 Forbidden');
}

2. On every meza deploy do curl localhost:8080/flush-cache.php

This seems less invasive to me than doing an Apache restart which could cause users to lose data.

Ref: https://ma.ttias.be/how-to-clear-php-opcache/

[freephile]

You chose this number based on the number of PHP files in /opt/htdocs and /opt/.deploy-meza I assume? What if an install has a substantial number of large extensions? By default we may want to make this larger...with plenty of room to add extensions, but could make the value configurable via public.yml for systems that want to dial in the efficiency.

I think we could raise it to ~10000 without losing efficiency, and that would be good for almost anyone because I based the number on my QualityBox demo with 101 extensions.

[jamesmontalvo3]

@freephile I'd like to experiment with this on one of our dev servers a bit. I've changed the branch it pulls into to keep it out of master for now. I'll load it on a dev server and give it a try and go from there. Thanks for the commit! Sorry for the huge delay.

[jamesmontalvo3]

@freephile is there an issue with having Opcache.max_accelerated_files be 20000 even though that's larger than it needs to be? Having it bigger than we need with base Meza leaves room for local extensions.