[wp-trac] [WordPress Trac] #15304: New file-based persistent cache

[WordPress Trac]

#15304: New file-based persistent cache
-------------------------+--------------------------------------------------
 Reporter:  mrasnika     |       Owner:                 
     Type:  enhancement  |      Status:  new            
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Cache        |     Version:                 
 Severity:  normal       |    Keywords:                 
-------------------------+--------------------------------------------------
 I've read about the shortcomings of the original file-based persistent
 cache, that's been ditched since 2.5; I've also checked the available
 file-based cache implementations (wp-file-cache, neosmart's re-
 implementation of the original, even w3-total-cache with the W3_Cache_File
 class) and they all seem to have the same drawback: they save each cached
 entry in a separate file. This means that each hit or miss requires
 reading and writing to the file-system, making this approach useless.

 I have implemented a different approach towards file-based caching, which
 is a cross between the mem-based caching that is now in WP, and the file-
 based caching -- here's what I wrote in a reply to wp-hackers:

 ''"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."''

 ''"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."''

 I've attached the implementation as an object-cache.php so it can be
 tested, but I think that it can be used not just in this plugin form, but
 also to replace the mem-based cache that's now inside WordPress: it has
 all the advantages of the memory-based cache, plus it is persistent
 between pageloads. Additionally as stated above we are using only core php
 features like includes and var_export(), and there is no performance
 penalty for serialization/unserialization.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/15304>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software