Cache or Query??

[MattR]

I've just updated my Social Sites plugin so it caches the list of sites you've set up, to save a query when they're used on the forum. All the forms to configure the Social Sites still query (I prefer to use a query in areas like that to 'make sure' it's got all the current data and not an outdated cached version), but on pages that display them and will get hit heavily on big forums (profiles and showthread), it reads the cache.

My question is this: when the plugin is newly installed, the cache of sites is 2KB... not a lot, but if people add lots of sites it'll obviously get bigger. Things like this get cached to save queries, as it'll be quicker to use a cached array than query and build an array on every page load, but when does the increase in the memory footprint outweigh the benefit from saving a query?? I mean, when viewing a thread, and the icons for social sites are displayed in the postbit, it'd only query the database once, at the start of showthread.php; would it ever get to a point where it'd be better to just have a query, rather than store a big array in the cache, which, by the nature of how the cache works, would be loaded on every page load instead of just where it's needed??

Basically; query on showthread.php which could get a lot of hits, or a possibly large cache being loaded on all pages?? Which is better?? I'd have thought a cache won't always be more efficient than a query, because it's loaded on all pages.

[ZiNgA BuRgA]

Since it rarely gets updated, and unlikely to have a lot of entries (having a lot of sites is going to be awkward) so the cache seems fine to me.
As you said, it's a bit of a tradeoff between memory usage, and possibly filesystem usage (if cache is stored in files) vs a separate query.

I wouldn't be too concerned about the relatively small amount of memory overhead for that plugin.  Remember that code itself is loaded into memory, including all PHP interpreter overheads, and the plugin file probably consumes quite significantly more than 2KB on every page load.  My first point of call to reducing the amount of memory usage would be to split up code that's rarely loaded (ie ACP stuff) into a separate file.  This actually possibly does more than you think, including less code loaded, less code that needs to be parsed, and potentially less stress on an opcode cache.  If you can't be bothered to really do that, then I wouldn't worry about the overhead of the datacache.
But if you do, there's some things you can do to reduce memory with the cache:
- remove stuff you never use, eg 'ssid' (actually, it seems that you never use it - I'd personally make 'nicename' the primary key)
- make your own simple cache - not hard to do, just simply export stuff to a file in the cache directory, and you can only load it during showthread
MyBB's memory cache (memcache, xcache etc) is kinda pointless, in fact, the idea of MyBB's cache has gone a bit wonky and it doesn't quite fit the typical definition of a cache, but nonetheless...

[Firefox Wins]

(01-22-2011 11:38 AM)ZiNgA BuRgA Wrote:  ...
MyBB's memory cache (memcache, xcache etc) is kinda pointless...

That (fairly small) amount of data is accessed so frequently.
What is the best choice for the 'datacache' table?
memcache
db
or
Files?

[ZiNgA BuRgA]

It doesn't really matter that much IMO.

[frostschutz]

PluginLibrary offers an alternative caching method that avoids the database entirely. So it's a cache without autoload or persistence. It will be loaded on demand only.

It still uses the MyBB cache handlers though. By default that's the disk cache handler, but if you've set up your board with memcached or xcache, it will still use that.

However, without database, it means that if the cache is deleted for some reason, because you deleted the file, or memcache rebooted, or decided to throw it out to make room for something else, the only way to get it back is to regenerate it. MyBB's cache would just query it back from the database instead.

So which cache method to choose depends on whether you want or need MyBB's autoload and persistence, or not.