On 23/02/2007, at 1:51 PM, Daniel Sheppard wrote:
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
Daniel,
What I was suggesting wasn't that Page.find_by_url be called on every
page request.... The original email was about changes to the caching
mechanism...
My suggestion, working from your outline:
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) call the page.headers method to set the page headers
d) send /cache/<url>.data
else
e) Call Page.find_by_url to find the page
f) call the page.headers method to set the page headers
g) call the page.render method to render the page content
I was saying that the headers could be sent on every request. This
allows ACLs to work for the main site pages... at the moment (as I
understand it) the headers - so this includes session info - are
cached and only update once per 5 minutes... This is unworkable if
you want conditional content -
ie if user registered
show registered_user_page
else
show login_page
I certainly wasn't saying that page caching wasn't needed, and can
even see how powerful the radiant caching is since it essentially
turns the site into static content, once cached. But caching headers
doesn't seem workable in the long-term - or will need to be at least
an option in the caching mechanism in order to implement more dynamic
behaviour. Of course this then opens up the site to all kinds of
dynamic content and caching by page url would not work... since two
users could potentially have different pages with the same url... but
it at least allows session data to be used on a page by page basis...
Perhaps caching page parts would work?
Anyway this is all stuff that will have to be worked out if blogging
is going to be possible with Radiant...
Cheers,
Adam
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
_______________________________________________
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
