How do I tell if a block supports full-page caching?
Permalink
I have a client complaining about the speed of their site, and the frequency of crashes. They're on a Rackspace cloud server, and I've noticed that some days--there doesn't seem to be any pattern--their site is slow and frequently throws server errors.
I assume this is because of the number of database calls (not just their site, either), so page caching would help. I have full-page caching enabled, but at the setting labeled "Use global setting - cache page if all blocks support it." And I don't know if it's working, because what if all blocks don't support it?
How do I tell?
I assume this is because of the number of database calls (not just their site, either), so page caching would help. I have full-page caching enabled, but at the setting labeled "Use global setting - cache page if all blocks support it." And I don't know if it's working, because what if all blocks don't support it?
How do I tell?
Thanks, Jordan.
If the code doesn't match your sample, can it be edited? Some of these blocks I did myself, just basing them off other blocks; and while they work, I can't claim they're in any way optimized (I didn't even know about this aspect, for instance).
As an example, one menu block (it's a restaurant site) has this:
So for that block can I change the one "false" to "true," and add "protected $btCacheBlockRecord - true;" without breaking something?
If the code doesn't match your sample, can it be edited? Some of these blocks I did myself, just basing them off other blocks; and while they work, I can't claim they're in any way optimized (I didn't even know about this aspect, for instance).
As an example, one menu block (it's a restaurant site) has this:
protected $btTable = 'btCateringMenuItem'; protected $btDescription = "Block containing Catering Menu information"; protected $btName = "Catering Menu Item"; protected $btCacheBlockOutput = true; protected $btCacheBlockOutputOnPost = true; protected $btCacheBlockOutputForRegisteredUsers = false;
So for that block can I change the one "false" to "true," and add "protected $btCacheBlockRecord - true;" without breaking something?
Yes, you can change those settings in the controller and it shouldn't break anything. I think you might need to "refresh" the block in order for them to take effect (if these are custom blocks, go to Dashboard -> Block Types, click on the block, click the "Refresh" button... but if they're blocks in a package you need to go through the Add Functionality dashboard page I think).
Note that depending on what your blocks actually do, having them cache stuff might make them not work the way you want -- for example, if a block shows some info about the logged-in user, you don't want to cache that for logged-in users because it will show some other user's data. Basically, if the block always shows the same thing every time a page is viewed, then caching is ideal. But if the block shows different things every time the page is viewed, then caching is probably not going to be a viable option. Of course there are grey areas in the middle you'll have to experiment with and use your judgement for.
Note that depending on what your blocks actually do, having them cache stuff might make them not work the way you want -- for example, if a block shows some info about the logged-in user, you don't want to cache that for logged-in users because it will show some other user's data. Basically, if the block always shows the same thing every time a page is viewed, then caching is ideal. But if the block shows different things every time the page is viewed, then caching is probably not going to be a viable option. Of course there are grey areas in the middle you'll have to experiment with and use your judgement for.
Again, thanks. One last question: we've already broached the possibility of moving the website off Rackspace. Do you have a recommendation?
Actually, another question: I don't see "Dashboard > Block Types." This is 5.4.4.1...is that a 5.5 thing? I do see "Refresh core database tables and blocks" under "Sitewide Settings > Debug." Is that the same thing?
In 5.4, it's Dashboard -> Add Functionality, then click on the block in question, then you should see the 'refresh' button. (Not "Refresh core database tables and blocks".).
As for hosts... search the forums for more recommendations... but for shared hosts I've had good luck with BlueHost, HostGator, and Dreamhost. For VPN's, they're all pretty much the same -- I've had luck with HostGator VPN and Dreamhost VPN.
ALso had good experience with MediaTemple and Rackspace (as long as you are *NOT* using the "cloud" thing)... but they are much more expensive than others.
A good compromise might be this:
http://c5spot.com/
They're a re-seller of rackspace hosting I believe, but have it tuned to work well with C5. Haven't used them myself yet, but looks like a promising option.
-Jordan
As for hosts... search the forums for more recommendations... but for shared hosts I've had good luck with BlueHost, HostGator, and Dreamhost. For VPN's, they're all pretty much the same -- I've had luck with HostGator VPN and Dreamhost VPN.
ALso had good experience with MediaTemple and Rackspace (as long as you are *NOT* using the "cloud" thing)... but they are much more expensive than others.
A good compromise might be this:
http://c5spot.com/
They're a re-seller of rackspace hosting I believe, but have it tuned to work well with C5. Haven't used them myself yet, but looks like a promising option.
-Jordan
Much obliged for all your help, Jordan.
Hey Jordan,
can you explain what $btCacheBlockRecord exactly does or when to activate it?
Thanks in advance!
can you explain what $btCacheBlockRecord exactly does or when to activate it?
Thanks in advance!
I actually don't know. I was going to link to this thread where @mkly explains it:
http://www.concrete5.org/community/forums/documentation_efforts/spe...
...but I see you're on there as well so maybe you're looking for a more detailed answer (which unfortunately I don't have myself -- but would love to know).
This would be a good thing to ask on the TV show next week. And to bug the core team about documenting :)
http://www.concrete5.org/community/forums/documentation_efforts/spe...
...but I see you're on there as well so maybe you're looking for a more detailed answer (which unfortunately I don't have myself -- but would love to know).
This would be a good thing to ask on the TV show next week. And to bug the core team about documenting :)
Ahhh... the lost Active Record implementation in the c5 core.
I think it actually did nothing for a while. I believe the intention was to cache block data but... In actuality I think it was used as a kind of almost Active Record thing which is also the reason I believe we will never have an updated adodb with the working Active Record.
What happens when btCacheBlockRecord is set to true is that BlockController::load() is called.
If you check out the BlockController constructor you can see it happen.
The hilarious part appears to be that the BlockController constructor also calls load(). So that would make it seem pretty redundant. I haven't tested it as I just got the word that the likelihood of adodb's active record being upgraded to the fully functioning version is slim to nil.
So my gut is that it was intended to be a way to have your Block's datafields available in the view like you are probably used to. But then at some point everyone got it, which means that it's one of the many legacy holdovers in the source that probably doesn't do anything.
But I could be wrong. That's just my current untested guess. Would love to find out otherwise.
I think it actually did nothing for a while. I believe the intention was to cache block data but... In actuality I think it was used as a kind of almost Active Record thing which is also the reason I believe we will never have an updated adodb with the working Active Record.
What happens when btCacheBlockRecord is set to true is that BlockController::load() is called.
If you check out the BlockController constructor you can see it happen.
The hilarious part appears to be that the BlockController constructor also calls load(). So that would make it seem pretty redundant. I haven't tested it as I just got the word that the likelihood of adodb's active record being upgraded to the fully functioning version is slim to nil.
So my gut is that it was intended to be a way to have your Block's datafields available in the view like you are probably used to. But then at some point everyone got it, which means that it's one of the many legacy holdovers in the source that probably doesn't do anything.
But I could be wrong. That's just my current untested guess. Would love to find out otherwise.
To answer your specific question, though, you need to look inside the block's controller.php file to see its cache settings. Look for some code like this:
If you don't see that stuff at all, then the block isn't caching. And if any of them are set to false, that specific aspect of caching is disabled.
But I doubt this will address the speed concerns (who knows, though... worth a shot).