A proof of concept cache system
Permalink 3 users found helpful
Hi people,
there has been discussion on the forums lately about whether concrete5 is slow, not slow, heavy, picky with servers, etc. On some servers, there is no doubt though that C5 can feel a bit sluggish, even with it's caching enabled as there is significant overhead to simply do a page load, hitting the database, etc. So I thought I would look at a simpler way of caching that comes into play before concrete5 has a chance to fully load.
Although it is working quite well one of my test sites so far, this is still a proof of concept as such. I'm keen for feedback.
I wasn't going to pretend that I knew the intricacies of file locking for caching, etc, so I've used the Cache_Lite class from the PEAR framework. It didn't require the rest of pear, just a config item to tell it not to load in anything from pear.
I then created a class to handle the triggering of the caching. This class looks for some particular factors when to not use the cache, when to clear it, etc.
I based it on the following thinking:
- Unless there was is reason to refresh a page, by default indefinitely cache the page. Most of my sites are fairly static.
- If someone does a GET or POST, don't cache it at all.
- Test for being logged in, if logged in disable caching.
- If someone views any of the site while logged in, blow away the cache. It's a bit brute force, but it adds little overhead and it is only while someone is logged in.
To install - see the notes on my blog link below.
Some caveats
- I found that with Concrete5's caching on there were a few times where pages wouldn't update, so caching should be disabled.
- I've done my best to stay out of the core files, but view.php does need to be overridden, and dispatcher.php edited. No other way around it. Be careful in the future if you update the core concrete Library.
- It only works at this stage for pretty urls.
- The cache doesn’t support CSS and Javascript that are linked via index.php. So in the theme, don’t use the getStylesheet function, use getThemePath instead and directly link the resources.
- Pages that have dynamic content from other sources like RSS feeds should be added to the BOOTSTRAPCACHE_CACHE_TIME_SPECIFICS array, specifying an appropriate refresh time. Keep in mind that if an end user moves/renames pages with dynamic content, there is the possibility of pages never refreshing. To avoid this, perhaps set a default cache time to a non null value.
I hope someone finds this useful. For me it makes a few sites start to feel like static sites, which is a good thing!
A zip of what I have created can be found on my site (the post is almost the same content as this post, so just scroll to the bottom).
http://www.mesuva.com.au/2011/03/an-extra-cache-for-concrete5/...
Cheers
-Ryan
there has been discussion on the forums lately about whether concrete5 is slow, not slow, heavy, picky with servers, etc. On some servers, there is no doubt though that C5 can feel a bit sluggish, even with it's caching enabled as there is significant overhead to simply do a page load, hitting the database, etc. So I thought I would look at a simpler way of caching that comes into play before concrete5 has a chance to fully load.
Although it is working quite well one of my test sites so far, this is still a proof of concept as such. I'm keen for feedback.
I wasn't going to pretend that I knew the intricacies of file locking for caching, etc, so I've used the Cache_Lite class from the PEAR framework. It didn't require the rest of pear, just a config item to tell it not to load in anything from pear.
I then created a class to handle the triggering of the caching. This class looks for some particular factors when to not use the cache, when to clear it, etc.
I based it on the following thinking:
- Unless there was is reason to refresh a page, by default indefinitely cache the page. Most of my sites are fairly static.
- If someone does a GET or POST, don't cache it at all.
- Test for being logged in, if logged in disable caching.
- If someone views any of the site while logged in, blow away the cache. It's a bit brute force, but it adds little overhead and it is only while someone is logged in.
To install - see the notes on my blog link below.
Some caveats
- I found that with Concrete5's caching on there were a few times where pages wouldn't update, so caching should be disabled.
- I've done my best to stay out of the core files, but view.php does need to be overridden, and dispatcher.php edited. No other way around it. Be careful in the future if you update the core concrete Library.
- It only works at this stage for pretty urls.
- The cache doesn’t support CSS and Javascript that are linked via index.php. So in the theme, don’t use the getStylesheet function, use getThemePath instead and directly link the resources.
- Pages that have dynamic content from other sources like RSS feeds should be added to the BOOTSTRAPCACHE_CACHE_TIME_SPECIFICS array, specifying an appropriate refresh time. Keep in mind that if an end user moves/renames pages with dynamic content, there is the possibility of pages never refreshing. To avoid this, perhaps set a default cache time to a non null value.
I hope someone finds this useful. For me it makes a few sites start to feel like static sites, which is a good thing!
A zip of what I have created can be found on my site (the post is almost the same content as this post, so just scroll to the bottom).
http://www.mesuva.com.au/2011/03/an-extra-cache-for-concrete5/...
Cheers
-Ryan
Sound promising. Thanks for posting.
Hi Mesuva,
I have NEVER found Concrete5 slow, frustrating at times and really for me a shallow learning curve, but what I do find is certain elements slow it down.
like all things in life??
Templates, Scripts, Themes, Coding, Misunderstanding, Interfering, Fiddling, Typo's, Bulking and Bloating........Whoops!
Is your example going to help me or my client?
Do I have to learn more stuff and then teach clients?
Or is this developer stuff?
Sorry not sure of your direction!
Regards
Steev
I have NEVER found Concrete5 slow, frustrating at times and really for me a shallow learning curve, but what I do find is certain elements slow it down.
like all things in life??
Templates, Scripts, Themes, Coding, Misunderstanding, Interfering, Fiddling, Typo's, Bulking and Bloating........Whoops!
Is your example going to help me or my client?
Do I have to learn more stuff and then teach clients?
Or is this developer stuff?
Sorry not sure of your direction!
Regards
Steev
I'm glad you've never found Concrete5 slow, if that is the case, then my cache is not really for you! Although it is pretty much a drop in component, it is something that only a developer would add. Nothing to do with clients.
This is for cases where a site is running a bit slow and/or when you might want to cope with a high level of traffic for a while. It's perhaps not really much different than other file based caching systems, but this is developed for Concrete5 specifically.
I developed it for one of my sites and simply thought I would share it in case others found it useful.
This is for cases where a site is running a bit slow and/or when you might want to cope with a high level of traffic for a while. It's perhaps not really much different than other file based caching systems, but this is developed for Concrete5 specifically.
I developed it for one of my sites and simply thought I would share it in case others found it useful.
Ok,
I bow out.......................
I bow out.......................
Hi Mesurva,
I have the caching working (wow it really speeds the site up) but now when I try and log into the system, it shows two log in screens, stacked. In the code it is outputting 2 full pages (like its outputting the whole cache twice.)
When I log in, it sends me to the dashboard but shows 2 login screens.
Here is my site.php
Any thoughts?
I have the caching working (wow it really speeds the site up) but now when I try and log into the system, it shows two log in screens, stacked. In the code it is outputting 2 full pages (like its outputting the whole cache twice.)
When I log in, it sends me to the dashboard but shows 2 login screens.
Here is my site.php
define('URL_REWRITING_ALL', true); // BOOTSTRAPCACHE // caching switch define('BOOTSTRAPCACHE', true); // turn on a visible message to test caching define('BOOTSTRAPCACHE_DEBUG', true); // set the default cache time in seconds, null means indefinitely cache define('BOOTSTRAPCACHE_DEFAULT_CACHE_TIME', 10); // pages that should not ever be cached should be placed in this array. define('BOOTSTRAPCACHE_EXCLUDED_PAGES', serialize(array( '/dashboard/', '/indes.php/dashboard', '/indes.php/dashboard/', '/index.php/login', '/index.php/login/',
Viewing 15 lines of 20 lines. View entire code block.
Any thoughts?
This cache was something that worked fine for 5.4.x, but with 5.5.x it creates issues (at least if you install it the same way as before).
But I have got this to work with 5.5.x. Try:
- downloading the most recent version off of my site
- removing the URL_REWRITING_ALL from your config, as well as the BOOTSTRAPCACHE_EXCLUDED_PAGES (not needed)
- Most importantly don't replace/edit dispatcher.php as per the original instructions.
Instead, simply make one edit, place:
include('libraries/bootstrapcache/bootstrapcache.php');
towards the end of dispatcher.php, just above: $v = View::getInstance();
Doing it this way isn't quite as fast as before, but it doesn't muck up sessions, etc.
But I have got this to work with 5.5.x. Try:
- downloading the most recent version off of my site
- removing the URL_REWRITING_ALL from your config, as well as the BOOTSTRAPCACHE_EXCLUDED_PAGES (not needed)
- Most importantly don't replace/edit dispatcher.php as per the original instructions.
Instead, simply make one edit, place:
include('libraries/bootstrapcache/bootstrapcache.php');
towards the end of dispatcher.php, just above: $v = View::getInstance();
Doing it this way isn't quite as fast as before, but it doesn't muck up sessions, etc.
Thanks for the reply, I will try it out tomorrow. you might want to
update the howto!
-Cheers, Andrew
On 08/06/2012 07:00 PM, concrete5 Community wrote:
update the howto!
-Cheers, Andrew
On 08/06/2012 07:00 PM, concrete5 Community wrote:
Hi Thanks for your reply!
I tried this, and it seems to work, except when I am logged in if I hit the home page (/) it gives this error in my browser:
Content Encoding Error
The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.
If I enterhttp://development.demo.i-evolve.net/index.php/... (trailing index.php) everything seems to work.
When I am NOT logged into the system the root page works fine as just /.
Removing url rewriting as noted in your new instructions seems to fix the issue. Is the bootstrapcache currently incompatible with url rewriting? That would limit is usefulness as clients really like their pretty urls =).
We've been having lots of speed issues with c5 in our server setup. We are doing a conference call with c5 for support for this issue, but I was hoping this caching mechanism could be made to work as well, as it seem pretty fast. Other than the few bugs it seems to work awesome. Any interest in getting some help for testing debugging so we could get this full operational?
Regards,
Andrew
I tried this, and it seems to work, except when I am logged in if I hit the home page (/) it gives this error in my browser:
Content Encoding Error
The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.
If I enterhttp://development.demo.i-evolve.net/index.php/... (trailing index.php) everything seems to work.
When I am NOT logged into the system the root page works fine as just /.
Removing url rewriting as noted in your new instructions seems to fix the issue. Is the bootstrapcache currently incompatible with url rewriting? That would limit is usefulness as clients really like their pretty urls =).
We've been having lots of speed issues with c5 in our server setup. We are doing a conference call with c5 for support for this issue, but I was hoping this caching mechanism could be made to work as well, as it seem pretty fast. Other than the few bugs it seems to work awesome. Any interest in getting some help for testing debugging so we could get this full operational?
Regards,
Andrew
I've not seen that content encoding error before. Not sure about that one.
Bootstrapcache is definitely compatible with pretty urls, in fact it's a requirement.
The line I suggested you take out is to make ALL pages rewritten without the index.php (so the dashboard, etc), which is not really necessary. I'm pretty sure with that extra setting in place, the cache system would get mixed up.
I have seen the page doubling up before, but I'm fairly certain I fixed it by not mucking around with dispatcher.php like in my original instructions. For 5.5.x it now should be just a single addition of the one include() line.
I'm happy to help you sort out these problems where I can, as I wouldn't mind improving this further. However... I'll stress though that what I released here and on my blog really was a 'proof of concept'.. more of an idea for a caching possibility than anything else. My concern with something like this is that it isn't fully tested for the whole range of things concrete5 does, for different packages, etc. It also means you'd need to reapply manual code changes every time you updated concrete5.
I only use it myself when I have no choice but to leave a site where it is AND if a site is very simple. Otherwise, I just move websites to better servers. I just make sure I choose a decent host. I use shared hosting and I've found some great hosts that run concrete5 blazingly fast.
Bootstrapcache is definitely compatible with pretty urls, in fact it's a requirement.
The line I suggested you take out is to make ALL pages rewritten without the index.php (so the dashboard, etc), which is not really necessary. I'm pretty sure with that extra setting in place, the cache system would get mixed up.
I have seen the page doubling up before, but I'm fairly certain I fixed it by not mucking around with dispatcher.php like in my original instructions. For 5.5.x it now should be just a single addition of the one include() line.
I'm happy to help you sort out these problems where I can, as I wouldn't mind improving this further. However... I'll stress though that what I released here and on my blog really was a 'proof of concept'.. more of an idea for a caching possibility than anything else. My concern with something like this is that it isn't fully tested for the whole range of things concrete5 does, for different packages, etc. It also means you'd need to reapply manual code changes every time you updated concrete5.
I only use it myself when I have no choice but to leave a site where it is AND if a site is very simple. Otherwise, I just move websites to better servers. I just make sure I choose a decent host. I use shared hosting and I've found some great hosts that run concrete5 blazingly fast.
I am using Hostgator now which seems to be pretty fast. What hosts do you suggest?
I should have said 'I've found some great hosts in Australia'... elsewhere in the world, I'm not going to be much help!
If you're using Hostgator, and it seems pretty fast, then why are you using bootstrapcache? :-)
If you're using Hostgator, and it seems pretty fast, then why are you using bootstrapcache? :-)
I do development work using Concrete5 at my day job, and we just had a launch of a fairly large website that slowed to a crawl, which is baasically what led me to the bootstrap cache. We have since moved the site to its own server but for my personal site thats not so easy if my traffic gets high.... so looking at this as a possible measure to speed things up if needed.
Cheers
Cheers
