Right. Caching the complete url in the database would help,
but would
not work in all cases, i.e. virtual pages that represent
multiple urls.
Perhaps we should try this and get some metrics?
I was thinking that there would be a Page#calculate_urls method that
would by default just
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
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
OK. Point taken. I was really just putting my two cents in on a
subject that's important to me personally... ie user variable content
and ACLs.
It would be nice to do something like (I haven't actually looked at
the code, my bad):
page = Page.new
page.headers
page.content =
OK. Point taken. I was really just putting my two cents in on a
subject that's important to me personally... ie user variable content
and ACLs.
It would be nice to do something like (I haven't actually looked
at the code, my bad):
page = Page.new
page.headers
Maybe I need to dump my assumptions for a moment. Knowing the page that
we're about to be rendering from the cache would be a useful thing. Why
can't we do it? Because the performance of Page.find_by_url sucks.
I talked a little bit about that suckage a while ago, and somebody
(Adam? Sean?)
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
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.
Radiant currently caches only the page urls, without the params after
the ?
Am I the only one who thinks this is bad?
For example my products page listing works by
/products?offset=1200limit=10
and I must turn off caching to make this work. Why not just let the
cache
work on the full uri?
It also seems to be a good idea not to put post request's
response into
a cache.
A post supposed to change data, and the outcome of that should not be
cached - I should not say OK if you just signed up as root...
class Page
def cache?
request.get?
end
end
Perhaps that should be
Before changing how the caching works, I would ask, what are the reasons
for modifying caching. I can think of a few.
- It's annoying to have to clear page cache after every edit in order to
view your change.
The solution Dan suggests would make it possible to know exactly which
pages need
I don't see any. It's good enough for most cases, I believe.
The unmentioned alternative, of course, is memcached. It would
take minimal changes to the code, probably a single line in
environment.rb , since ResponseCache piggy-backs on the Rails caching
mechanism.
Well then can we make Apache serve everything? Why not have the options
to make Radiant generate a full directory of HTML files. A possible way
to support having select pieces of the site be dynamic is to use Apache
server side includes to make calls back to Radiant for specific pieces.
Daniel Sheppard wrote:
From looking at response_cache, there are only two features that it
implements that the default rails action caching didn't (easily):
- Expire Everything
- Expire After time
It also caches the entire response (headers + body).
Yeah, I left that off
Hi Dan, Ruben,
Actually I once build a commercial Enterprise CMS where a custom content
proxy would cache everything. It was flushed on time-out /and/ upon
changes in the content. The proxy allowed large companies to set up
caches wherever they pleased and still have a central repository. The
From looking at response_cache, there are only two features that it
implements that the default rails action caching didn't (easily):
- Expire Everything
- Expire After time
Am I missing something else? If I'm not, then I think I might have found
something that will give a big
Dan,
This sounds like a pretty good system.
I'm not sure if my suggestions/concerns are directly related caching,
but they kind of go with it.
The biggest hole in Radiant that I can see is that there is not proper
version management and publishing capabilities.
I work for a large state government
17 matches
Mail list logo
