[wp-hackers] should (can?) wp-cache be adopted into the core?

[David Chait]

I didn't ever specifically say 'in its current state'. ;)  Change it, 
tweak it, fix it, rewrite it.  But don't lose 'page caching' as an option.

Yes, there are problems with full-page caching.  First and foremost is 
that dynamic pieces have to be executed either as a pass-through loader 
(i.e., tagged as a jpg/png but actually a php file), or have to be via 
client-side methods (JS/ajax/whatever).  Secondly is when to invalidate 
the caching.  I didn't lose 10 minutes reading your spec, but a quick 
glance of it certainly looks interesting.  (Andy, I'm removing the end 
of your orig post just for length here... ;) ).

To other statements, not just andy:

I agree that moving wp-cache so it uses the object cache mechanism for 
storage might be useful for those cases where you have APC/memcached.  
HOWEVER, the importance of wp-cache is that it works WITHOUT those 
object-cache mechanisms, on shared hosts where they're not (generally) 
available.  AND, that the object-cache approach basically fails on 
shared hosting (again, in the old days it actually hurt performance if 
your host had well-configured mysql servers, especially if they were 
separate from the apache boxes -- don't know how it performs today).

I agree it should work across to IIS, that fixes are (apparently) 
needed.  However, reminder that wp-cache is the child of Staticize, so 
hopefully whatever problems are there might be easier to solve for the 
core team.

I don't like an approach that requires loading the entirety of WP in 
order to display a page.  The whole POINT of wp-cache/staticize was to 
NOT LOAD WP core, just short-circuit and dump out the cached page.

Yes, it 'breaks' dynamic stuff unless you use server/image-passthrough 
or client/JS approaches (OR, use the mfunc type thing from Staticize 
which has been rumored to have issues in recent wp-cache builds).  But, 
not all of us have dedi servers, let alone server farms, and running 
shared you need to trade off something for performance.  I learned long 
ago that surviving a slashdot was more important than a sidebar thing 
that changes if you refresh the page.  The basic blogger who wants 
purely dynamic, wacky, elements won't generally have traffic to worry 
about.  The heavy blogger probably has VPS or dedi and can put the 
object cache, with APC/memcached, plus generally use a PHP bytecode 
cache.  The midrange folks, without wp-cache, will quickly be 
'stranded', without performance tools to tune for reasonable volume on 
shared environments (which, again, can't usually, usefully, take 
advantage of the object cache or bytecode caching approaches).

Just imho. ;)

-d

Andy Skelton wrote:
> On 4/16/07, David Chait <davebytes at comcast.net> wrote:
>> Any reasons it shouldn't be in the core (even if it's kept as a
>> plugin...), while the object-caching approach IS?  Note that object
>> caching has, in the past, shown to be detrimental to performance on the
>> average shared hosting setup -- though on dedi setups, with APC or
>> memcached and/or php bytecode caching, I could imagine setups where the
>> object cache could beat out the wp-cache 'php page' caching system.  I
>> run on shared for cost+stability management, I'd run on a VPS if my site
>> really took off again.. ;)
>
> I would not like to see WP-Cache bundled with core in its current
> state. The object cache has come a long way. The object cache is not a
> substitute for WP-Cache, nor vice versa, but they are ignorant of each
> other when they should be cooperating or even fusing.
>
> What I want is for WP to have an object cache that is strong enough
> that rendered pages could be cached, retrieved, optionally mixed with
> dynamic content, served and appropriately invalidated using whatever
> object cache client suits the setup.
>
> In order to be compatible with full-page caching, all code (including
> themes, plugins, widgets, mods) must comply with several principles of
> caching that just haven't been codified yet. So those standards would
> have to be written and followed.