> I know this is a little late (email from last month)... but
> in regard
> to caching, isn't the major problem with implementing sessions in
> Radiant that the headers are cached as well? This seems to be over
> optimisation... Just cache the page text and let the headers be
> generated. Surely there isn't that large a hit in performance, and
> the advantage of using individual user sessions is great. Or make it
> an option at least, since most user ACL type systems require
> sessions...
To serve a page currently, the following steps are performed:
a) check for the existance of /cache/<url>.yml
b) check for the validity of /cache/<url>.yml
if file exists and is valid:
c) send /cache/<url>.data
else
d) Call Page.find_by_url to find the page
e) call the page.headers method to set the page headers
f) call the page.render method to render the page
content
A quick experiment to see the performance impact of making a
Page.find_by_url call on every request - using my current database
containing a few hundred pages, I'll pick a random deep page.
With the current caching mechanism, running:
ab2 -n 1000 -c 2
'http://localhost/articles/2006/04/13/2006-melbourne-international-comed
y-festival-reviews/levelland/'
I ran it first using the current radiant caching mechanism, and then
again modifying the site_controller to always do a Page.find_by_url
regardless of whether the page is cached or not.
Original cache : 160 requests / second
Modified cache : 4 requests / second
So, "Surely there isn't that large a hit in performance".... unless two
orders of magnitude doesn't constitute a large hit for you, I hope you
see why the cache behaves as it does.
Dan.
_______________________________________________
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
