[wp-hackers] What were the shared hosting issues with persistent file cache prior to WP 2.5 ?

[Kaloyan Tsvetkov]

K.

On Tue, Nov 2, 2010 at 6:24 PM, Otto <otto at ottodestruct.com> wrote:

> On Tue, Nov 2, 2010 at 10:18 AM, Kaloyan Tsvetkov <kaloyan at gmail.com>
> wrote:
> > I am doing some research on file-based caching and I read that persistent
> > cache was removed from WP since 2.5 and was replaced with in-memory one.
> The
> > reason for that were that the WP implementation was hardly introducing
> any
> > performance boost and that there were some issues with shared hosting.
> >
> > Does someone recall what these issues were, or at least where I can read
> > about them ?
>
> What Peter said. A large number of hosts use shared filesystems
> (especially "cloud" hosts) and accessing the filesystem over the
> network (be it via NFS or any other means) is slow.
>

I would guess that there would be some performance benefit if the "file
cache" is in the form of "pure php", so when you have to use that cache you
just include the file like any other php script you have included. That
combined with var_export() and using just one file for the cache (instead
one cache file per cache entry) probably is going to deliver better results.
At least there is no penalty for serialization/unserialization, and in this
way with the includes we are sort of hijacking the file-reading and
evaluation of their content by PHP itself.


>
> Also, even local filesystem access frequently isn't really any faster
> than database access in many cases. For example, if you're running a
> database server on the same machine, then the SQL query cache probably
> is storing a lot of the results of your common queries in RAM. Much
> faster to get them from there than to go load a file.


I did some testing, although I am not sure how legit is that, and on an
environment like shared hosting hardly 10% of the wordpress queries are
delivered from sql cache. Out of that 10% I am not sure how much are those
queries which output is being cached.


> Filesystem
> caching generally isn't very aggressive and so hits to that cache
> often miss, requiring it to go back to the disk.
>

I wrote about that above: what if all the cache entries are read/written in
bulk ? Take the current implementation for example (the mem-based): it
stores everything inside an array, so hits and misses only deal with that
array. If we save that array (with all the cached entries inside it) to file
when destroying the object (or with register_shutdown_function()), and then
include it when instantiating it, we are going to skip all the file-system
read and write operations. In the worst-case scenario there is just one
include (on an absolute path to be faster than include_path-based), and one
write to file when dumping the contents of the cache array. The rest is the
same -- the add/replace/set/get cache functions use the cache array.


>
> Like all things, it depends on the specific details of your setup.
> This is why it's best left to plugins to allow you to optimize as
> needed for your particular circumstances. If you have a big site, best
> way to do it is to use some kind of distributed memory caching, like
> memcached, for caching persistent objects.
>

Thanks, Otto. I am familiar with the available persistent cache options, but
almost all of them are hard to use in shared hosting environment. I am
looking for affordable solution to that problem. What I have in mind is
indeed file-based cache just as I explained it above, with include and
var_export(). Then I read that WP already had a file-based cache and ditched
it since 2.5 and I was curious to find out why. Thanks to your reply and
Peter's I now know what the issues were and I think that my approach can
produce somewhat promising results -- I just got to code it and test it ;)

Again, thanks for the replies.


>
> -Otto
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>