OPCache- set it up and let 'er eat.

Started by drewactual, January 14, 2018, 11:50:28 PM

Previous topic - Next topic

drewactual

just trying to give some back to the community here:

i've been playing with settings for a while now, in attempt to optimize a site.  i noticed that SMF in 2.0.x (mine is 15) doesn't recognize the zend accelerator's (somewhat) new name (OPCache)... but that's okay- you don't require SMF to handle it- you can set it up outside and let it handle the entire webspace you manage...

after testing this thing for a good bit, these are the settings and the actual entry to make... MOST php builds above 5.4 come with OPCache as part of it.. unless you went out of your way (or your server managers did) to keep from loading OPcache, it's on there...

in your php.ini or your .user.ini (depending on how you're set up) copy and paste this snippet:


zend_extension=opcache.so
opcache.memory_consumption=264
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1
opcache.use_cwd=1
opcache.load_comments=1
opcache.save_comments=1
opcache.revalidate_path=1
opcache.validate_timestamps=1


this is a safe place to start with OPCache... check out the php documentation for each line if you have any concerns.  you should notice a nice bump in your load speed after the caches start populating.  use this with memcached for another nice bump, (IF memcached is available) and by adding this snippet (also to php.ini or .user.ini depending on how your server is set up) :


extension=memcached.so
session.save_handler="memcached"
session.save_path="127.0.0.1:11211"


this passes sessions AWAY from the flat file on your server and passes it to the memcached server, and hands it off to the user to store on their machines- making retrieving the cache faster and cleaner, and for reducing the weight of your page.

you're system will be happy with your work.. however, there is yet more to do... you should set up expires for your cache globally...

exit the php.ini or .user.ini and navigate to your .htaccess.

this config works nicely:


# One year for image files
<filesMatch ".(jpg|jpeg|png|gif|ico)$">
Header set Cache-Control "max-age=31536000, public"
</filesMatch>
# One month for css and js
<filesMatch ".(css|js)$">
Header set Cache-Control "max-age=2628000, public"
</filesMatch>


what you've just done ^ is pretty evident with the notes provided, but in other terms you just told users to cache images for a year, and css and javascript for a month.  this takes a huge chunk out of what they have to download each time they arrive at your site.. using the settings in OPCache 'revalidate freq' and 'validate timestamp' set reasonably, your users will collect and store items that don't often change while not hording files that do change often enough.

there is yet another two items that work well with this... one is the http2 protocol and the other is using the 'push' it provides.  if there is any interest in this i can come back and include it here from a post i made earlier.  all of these, together, make for a pretty swift conversation- like old friends talking as opposed to meeting someone for the first time and having to negotiate all the formalities. 

all of these functions work well with SMF- with the caveat "You're mostly done with implementation and development", as IF you interject this as presented, your users will possibly have to dump their cache's in order to see any added functionality (just as performed by .js) or style (such as changes you've made to .css files) - and, if you recycled the names of images for the same location with a new image, users (or you) may not see it until the cache is cleared.  so... if you're in 'sitting back and relaxing, just tweaking here and there and maintaining mostly' mode, these changes will be awesome. 

thanks y'all!!!!

MobileCS

I've been using opcache for over a year now (migrated from APC cache) and it's fantastic.

I recommend getting a dashboard for it so you can easily check cache hit rate, memory usage, etc. You can also delete cache entries.

https://github.com/carlosbuenosvinos/opcache-dashboard

All you need is the opcache.php file.

LiroyvH

Quote
(IF memcached is available)

If it's not available, you install it. ;)
If you're suggesting using it in a shared hosting environment, I'd be really careful with that...
((U + C + I)x(10 − S)) / 20xAx1 / (1 − sin(F / 10))
President/CEO of Simple Machines - Server Manager
Please do not PM for support - anything else is usually OK.

Arantor

Note that what SMF caching is for is a data store, not a compilation cache. Careful not to conflate the two.

drewactual

Quote from: CoreISP on January 15, 2018, 12:58:36 AM
Quote
(IF memcached is available)

If it's not available, you install it. ;)
If you're suggesting using it in a shared hosting environment, I'd be really careful with that...

that is certainly the case with memcachE, but isn't memcachedD okay?  one use the phpsessionid, and the other uses a hash, right? 

I'm NO expert, but my understanding is that this is the case, but i could just as easily be wrong.  I almost included those functions in the configuration i offered up...

Arantor

They're two different APIs to the same thing...

drewactual

Quote from: Arantor on January 15, 2018, 01:49:40 AM
Note that what SMF caching is for is a data store, not a compilation cache. Careful not to conflate the two.

i didn't see this before... absolutely!!!  it is confounding to me at times, but the simplest explanation i've heard is:
data store is for items that don't change such as pictures and other static items such as javascript/css and html... the compilation is actual scripts (php in this case) that run and then are tossed, just to be re-run again when someone else request the same thing (such as dynamic page rendering)- those scripts are held in the servers RAM and not flushed but staged for the next opportunity to be ran. < that is the case w/OPCache.

it makes things a LOT faster at the risk of scripts changing in the interim, but which can be controlled with the "opcache.revalidate_freq=60" function... which i changed to 120 seconds... also, i have 264M reduced to 128M with zero inefficiency's, and commented out "opcache.validate_timestamps=1" (or you can set it to zero) to save that step...

note to others: you absolutely want "opcache.revalidate_path=1" set to 1, as SMF uses the same file name in different extensions- you want OPCache to search using the file directory too, which is what the value '1' does in this line... otherwise, you're going to get some strange behavior. 

right this second on one of my pages (the SMF one), OPCache is hitting 99.99% of the time and holding 758 scripts in RAM @ 49.74M of the 128M it's dialed to...

the advantage is most apparent when a user goes to POST something- cleantalk is slow in their validation, and apparently is stacks (que's) posts?  i've seen teh page take as long as thirty seconds from when a user hits 'post' to it actually rendering the post.  with the scripts held in RAM and instantly available to the next user (or even concurrently), BOOM- hit post, let clean talk validate, and it's up in a literal second or less.

as far as SMF caching... I'm considering, now that things are settling down as far as design and implementation, of moving to cache level 3 for all the static stuff to see how it handles itself.

drewactual

Quote from: Arantor on January 15, 2018, 03:38:52 AM
They're two different APIs to the same thing...

i'm totally confused about this... i read a lengthy article describing the differences and then another that seemed to back up what the first had said... and all the while, the amount of confusion not only about the names, but what they do and how- seems to be as clear as mud.   I'm going to read some more..... I know they're related, but i was under the understanding that using memcacheD for sessions handling was far superior to using memcachE for the same... < which is how i'm using them.  SMF tells me "we've detected memcached available on your server", and the setting was ALWAYS level one whether memcached was operational or not (i went out of my way to install it, so my message was red before i did so saying 'no accelerator available')... i DID set the 'memcachE' settings- using 127.0.0.0:11211, and all 'seems' well... I haven't had any errors either SMF or server side involving it since i set it up...

i'm really curious as to what you describe- (no doubt trufe) :) ... i just need to educate myself on it. 

Arantor

Quotedata store is for items that don't change such as pictures and other static items such as javascript/css and html..

No, it isn't. A data store in these terms is for storing data. I.e. like running queries and storing the result so you don't have to hit the database so hard.

Quotehit post, let clean talk validate, and it's up in a literal second or less.

Eh? I've literally never seen opcache make that dramatic level of speed up. I assumed the problem was the remote call to their servers which should make no difference in terms of opcache.

Quotecaching... I'm considering, now that things are settling down as far as design and implementation, of moving to cache level 3

It will look sluggish and broken where things don't update so often because they're always using caches of things. Like the number of posts in a board. Heck even the drop down says level 3 is not recommended.


They are still two different ways of talking to a memcache server. One is more efficient than the other, but ultimately they still do the same job. The D on the end means "daemon", a word for a server process.

drewactual

i'm thinking the cleantalk script is pretty exhaustive by itself... it is the 10th most hit script on the page.  the reach out just references a txt file, right? it checks if that txt file has been updated, and if not- it goes ahead with the process is my understanding. 

aye- about the data store... honestly, i intermingle the types of cache's way too fluidly and automatically, and lose traction in thought quickly unless i slow down and validate my thinking (i can't rely on my own internal cache, in other words) :)  .   

yup, i knew memcached was a daemon, but i DIDN'T know the D was for Daemon... makes sense, too... i also know that i installed two packages- one that had memcached AND memcache, and the other which was just memcached. 

i don't really need to worry about any further cache settings or really anything else right now- so level three was just me speaking out of turn and off the top of my head... the site is faster than it's ever been on second + hits... it dropped in speed score index's, but because of adverts i'm running feeding from other places.  i can't really control them... i AM thinking about reducing them for less # but larger ads, though, to reduce the calls.

i also need to take more advantage of http2 push's- i'm only pushing a few files right now... i could likely bump that up quite a bit with little impact to resources or server.

another thing about using OPCache- my processor percentage is WAY lower than it was... not a little, a LOT. 

Arantor

Quotethe reach out just references a txt file, right

So it's network traffic which is bound to have fluctuations, and is wholly dependent on things you can't really influence.

Quoteyup, i knew memcached was a daemon, but i DIDN'T know the D was for Daemon... makes sense, too... i also know that i installed two packages- one that had memcached AND memcache, and the other which was just memcached.

So this is where it gets super confusing because naming things is hard.

There is memcached itself - this is the server process that actually does the work.

Then there is the memcache library which is the non-daemon part and connects to it. So far, so logical - the lack of a d on the end is consistent as it's not a daemon.

Then someone made memcached as a library - logical, it's a library that connects to a thing called memcached, but now it muddies the waters massively.

I have no idea which of these you have really installed...

Quotei also need to take more advantage of http2 push's

Part of the problem with this is it's not always going to be clear when a given resource will be needed. You can say for certain that a bunch of things will be needed at any time but there's a lot of dynamically added stuff that most servers don't handle that well right now.

Quoteanother thing about using OPCache- my processor percentage is WAY lower than it was... not a little, a LOT.

This makes sense, since it's not having to go through and re-parse all the PHP every time.

Oh and by the way if you haven't already, turn off template eval in server settings.

Advertisement: