Partial Caching, the way it should be

[eluser]Yorick Peterse[/eluser]
[quote author="Phil Sturgeon" date="1246913972"]It doesnt "cache it over and over" im just trying to work out if this really adds any benefit. If the HTML was being cached along with the data then it would help, but if both are being cached separately (or the data not at all) then this method will be slower or about the same... right?

I don't mean to be argumentative, i'd live to be proved wrong if you get this going and have some numbers for us.[/quote]

Aah now I understand. Problem is I really don't know. I'd say it wouldn't be that much faster, it would rather shift the load from the database to the I/O, or atleast balance it in a better way.

[eluser]Yorick Peterse[/eluser]
How about seperate cache files for each logged in user ? Like index_guest.cache, index_yorick.cache etc ? I'd say that would work, but you would end up having many, many cache files in the end.

[eluser]ntheorist[/eluser]
I've been tackling this problem too. From reading up on various caching methods, it seems like a combination of CI page caching and opcode caching are the way to go. Thankfully this can be employed on a perpage basis, so static pages stay static and fast. Good info on Elliot Haugin's blog

as for partial caching, there are many possible conditions that need to be met. if i'm going to cache block A for products/view, it may have different data than block A (being the same view file) on products/cart. Block B may be a static block, and can be cached and reused everywhere speedily. Block C has, like you point out, user-specific data. Plus all blocks fit in a template which again depends on the uri. It seems the only way to avoid exponentially multiplying the size of your cache dir (and losing performance in having to scan huge dirs) is to cache in 3 separate ways, view cache, data cache and userdata cache.

view caching would actually be redundant because your views folder could act as the cache for that. Unless they needed to be parsed (which i'm doing from the db to create the view file with a cms), all most views need are an array of data and use of if, foreach and echo.

The data caching is where you would save the most processing. I would love to try memcached, as ram is wayyyy faster than file reads hands down and it has a very basic interface with which you could EASILY cache data and serve it to a view before processing it, but unfortunately it turns out if you don't have a system with it installed, getting it onto a host can be a pain - i'm running a vps at mediatemple and so far getting memcache to work would require recompiling PHP, running phpize, installing their dev tools, working with ssh command access (foreign territory to me.. i'm not a -nix guy) i'm not too keen on finding out i've messed up my servers on which i'm hosting several clients already..

I found a file-based caching class that is similar in interface to memcache, here. It turns out the guy actually made it for CI so it might play nice, although i'm not crazy about serialize functions but for moderate data sizes it may work nicely. then you could store data combining your controller/method and /path/to/view as a key

userdata cache may not be necessary as it could all be stored in the session and retrieved upon login or read cookie id, and then carried in the session array. The problem, i guess, is how to inject the data into the view. Merge the data and userdata arrays? or create a global way for views to retrieve session data ( echo user_data('username'); ) - i'm not a fan of parsing on the fly, btw.. views need to contain logic and parsing on every call is a huge waste of time imo. Parse once upon editing a view and let it run as native php.

All this unfolds as well into a sequencing problem. If full page cache fails you will be loading the CI classes plus your controller/method (or in _remap) where you perform your view caching checks/processes, for any data not cached fire those processes and recache them, load session data and serve it as well.. There seems to be a lot of space between full page and partial caching options at the moment. Hooks may be an option, but it would be great to be able to configure settings, vars for controller/method to match cached data to view without having to actually call up the controller if not needed.

sorry for the long winded entry but this problem has been in front of me for a while and i feel like i'm inching closer to a solution that seems like the 'best' one (aside from memcache). I think i will give jon gales' library a test run and see how that works.

Also, literally at the moment i came across
Ocular, which seems to address the same issues we're facing. Let's hope more is less..

_n