Some pages, such as a Google sitemap, need to be generated dynamically
with each view, and never cached. It’d be nice to be able to mark them
as such, rather than manually going and clearing the cache before
regenerating it.
Similarly: A navigation plugin might need to be regenerated when -any-
page is saved, not just when the particular page it’s used on is
regenerated. I’m not sure if there’s a clean way to deal with that
right now, or what the best solution is - maybe a “depends-on-world” tag
which, if present, expires this snippet whenever any other response is
expired?
Jay L.
Jay L. wrote:
Some pages, such as a Google sitemap, need to be generated dynamically
with each view, and never cached. It’d be nice to be able to mark them
as such, rather than manually going and clearing the cache before
regenerating it.
I’ve considered it, and haven’t ruled it out, but it’s fairly easy to do
with a behavior:
class UncacheableBehavior < Behavior::Base
register “Uncacheable”
def cache_page?
false
end
end
Similarly: A navigation plugin might need to be regenerated when -any-
page is saved, not just when the particular page it’s used on is
regenerated. I’m not sure if there’s a clean way to deal with that
right now, or what the best solution is - maybe a “depends-on-world” tag
which, if present, expires this snippet whenever any other response is
expired?
Editing a snippet or layout will invalidate the entire cache.
–
John L.
http://wiseheartdesign.com
John W. Long wrote:
class UncacheableBehavior < Behavior::Base
register “Uncacheable”
def cache_page?
false
end
end
Perfect. I don’t think there’s any reason for a tag, then - anything
that’s going to be dynamic is going to involve code, and thus it can do
that.
Similarly: A navigation plugin might need to be regenerated when -any-
page is saved, not just when the particular page it’s used on is
regenerated. I’m not sure if there’s a clean way to deal with that
right now, or what the best solution is - maybe a “depends-on-world” tag
which, if present, expires this snippet whenever any other response is
expired?
Editing a snippet or layout will invalidate the entire cache.
Ah, but the problem is that if I edit a page somewhere else - say, I
change the title - the navigation snippet now needs to be regenerated,
but it doesn’t know that, because I didn’t edit it.
Jay
Jay L. wrote:
John W. Long wrote:
Editing a snippet or layout will invalidate the entire cache.
Ah, but the problem is that if I edit a page somewhere else - say, I
change the title - the navigation snippet now needs to be regenerated,
but it doesn’t know that, because I didn’t edit it.
But this is only a problem for a maximum of 5 min. As that is the length
of time a page is allowed to remain in the cache. Is that sufficient for
your needs?
–
John L.
http://wiseheartdesign.com
Jay L. wrote:
John W. Long wrote:
But this is only a problem for a maximum of 5 min. As that is the length
of time a page is allowed to remain in the cache. Is that sufficient for
your needs?
For mine personally, sure - I’m running a low-traffic site with 20
pages. I imagine larger sites might use a longer expire_time, though
that does push this suggestion into YAGNI-yet territory.
I’m not getting that kind of traffic on my own sites. And if you are I’m
sure you can afford to build your own content management system. 
There are all kinds of things that you can do when you get to that level
though. Use Apache to cache the site with mod_proxy, do load balancing,
etc… So assuming you haven’t built your own system at that point, you
have options.
Jason Hoffman was doing some testing on Radiant recently. He was getting
some pretty impressive stats:
http://forum.textdrive.com/viewtopic.php?pid=96828#p96828
I actually find this quite funny as I have done very little optimization
on Radiant. It just proves that the method used for caching static pages
was sound.
–
John L.
http://wiseheartdesign.com
John W. Long wrote:
Jay L. wrote:
John W. Long wrote:
Editing a snippet or layout will invalidate the entire cache.
Ah, but the problem is that if I edit a page somewhere else - say, I
change the title - the navigation snippet now needs to be regenerated,
but it doesn’t know that, because I didn’t edit it.
But this is only a problem for a maximum of 5 min. As that is the length
of time a page is allowed to remain in the cache. Is that sufficient for
your needs?
For mine personally, sure - I’m running a low-traffic site with 20
pages. I imagine larger sites might use a longer expire_time, though
that does push this suggestion into YAGNI-yet territory.
Jay
John W. Long wrote:
John W. Long wrote:
I actually find this quite funny as I have done very little optimization
on Radiant. It just proves that the method used for caching static pages
was sound.
There are a couple of pictures in his photo stream that feature Radiant.
I found this one impressive:
7 million on radiant behind a BIG-IP: throughput, connecti… | Flickr
Wow. OK, clearly I’m using old-school thinking on new-school hardware.
I was already thinking about how someday, Radiant would need a more
complex caching scheme, with snippet caching and dependency trees and
whatnot so the whole cache doesn’t need invalidation…
but YAGNI.
Cool.
Jay
John W. Long wrote:
I actually find this quite funny as I have done very little optimization
on Radiant. It just proves that the method used for caching static pages
was sound.
There are a couple of pictures in his photo stream that feature Radiant.
I found this one impressive:
http://flickr.com/photos/textdriveinc/179393665/in/photostream/
–
John L.
http://wiseheartdesign.com