Welcome Guest, Not a member yet? Register   Sign In
Caching or generating?

If people want to speed up their site they turn to cache solutions but why not serve generated static files to start with?

Let's take a blog for example. A blog page has two major parts, the blog post and the comments. Normally to build the frontend page you do something like
$data['post'] = $this->load->view('blog/post',$this->blog_model->post($id),true);
$data['comments'] = $this->load->view('blog/comments',$this->blog_model->comments($id),true);

With generated files you can do this
$data['post'] = include("blog/post_$id");
$data['comments'] = include("blog/comments_$id");

I left out all the security checks on purpose.

Why have a caching library that saves a partial or a page as a file where you have to use the library as an interface to manipulate the cache files if you can work it in your app and have full control over the files?
Cache libraries often put a lifetime on files but most of them are not hooked into the manipulating actions which can cause differences between the updated content and the frontend content.

Most pages on a site are almost static so why would you have to create them each time a visitor wants to see them? Why not use php just to glue pageparts together?

Of course these pages take up disk space but the time of 50mb or less hosting accounts are over and most of the time the user uploads will exceed the generated files space by a lot.

All comments are welcome

I must admit I have been pondering a similar question myself. The reason I cache the queries, or a set of queries, is that it's easier to have cache without expiration and always up-to-date when you can delete your cache relating to the query.

Using my MP_Cache library I can cache a query when its being read and delete it when its edited or deleted. Similarly I can write the cache for a listing of queries when I have the rules for those queries non-flexible so I can delete the (partial) listings when one of its entries is being edited or deleted. This creates caches that are non-expiring and always up-to-date...

... but this kind of caching only takes down the database-load and the problem of some (possibly) heavy post-processing is still there.

You can of course solve this by using CI's full page caching and depend on expiration to solve the problem of your cache not being current.

Another solution I'm looking into is doing it by something I called "dependencies" in my second version of MP_Cache. What I did is I started out with the first solution which caches the queries and than cached the full page afterwards as well. But the full-page cache has the rules that it's depending on the query-caches, which makes it refresh itself when one of those caches is newer than the full-page-cache itself. I'm just not sure whether this kind of checking might not become quite heavy on its own.

If you're interested, the (largely untested) code for my second version of MP_Cache can be found at http://mpsimple.mijnpraktijk.com/mp_cache.htm.

Well, some things update quite often, but for eg. the main content this seems like a very good idea/question.

Maybe combine that "static-files-cache" with push-updates?
So the caches only update when they are changed?
Then we gain even more, because it is only the admin panel which update the pages.

The pain point is indeed only being dependent on actions. if the design changes for example you have to write a script to update all the files for the change to have effect.

But i think if the site is not too complex you only need CI for the backend and for the frontend only php files to glue the partials together. Maybe just one controller that takes the responsibilities of the router too.

Theme © iAndrew 2016 - Forum software by © MyBB