----- Original Message -----
From: "Gianugo Rabellino" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, May 26, 2002 3:23 PM
Subject: Re: [VOTE] Adding "Expires" headers to pipelines
> Ivelin Ivanov wrote:
>
>
> >>1. Would you like this addition to be committed to HEAD? If so I promise
> >>to come up with documentations and a short HOWTO on how to connect a
> >>reverse proxy with Cocoon.
>
> > +1
> >
> > Is it possible that this is used in some fashion for dynamic pages as
well?
> > In some cases the Action or Generator would have information as to
whether
> > the underlying data model has changed and so they can in turn decide to
> > invalidate the cache.
>
> Hmmm... I'm not really getting it. By setting an Expires header you
> actually give up caching control to the client or to the reverse proxy,
> so once it's set it's not going to be invalidated anyhow. This might not
> be desirable.
>
> The point is what you think "dynamic pages" are. I see two scenarios:
>
> 1. real dynamic pages, e.g. built with request parameters, and changing
> everytime. In this case the Expires should never be set;
I will try to give a few examples, hoping they sound adequate to you:
a) Site search. Search results are not likely to change at least until the
content changes.
If the URL (for GET) or the POST parameters is the same then why bother the
search engine?
The probability of repetitive key phrases on a site is probably not
negligible, considering that either:
- the site is high volume, which means plenty of users hit it. The more
the users the higher the probability of repetition. Some recent research in
random graph theory has shown results in support of this intuitive
phenomenom. If you are subscribed to ACM, I will be publishing a review in
an upcoming issue of SIGACT News on "Random Graphs" by Bela Bollobas. An
there are of course plenty of other sources you can find on the subject.
- the site has specialized content (Cocoon), then the terminology is
limited (things like "transformer howto", "developer guide" would be amongst
the frequently used phrases) and probability of repetition is high.
- navigating (next, previous) through search results is supported
b) Authentication. Sophisticated app servers implement caching algorithms
which
- do not allow subsequent authentication requests with invalid credentials
for a certain period of time
- do not perform subsequent db round trips for valid authentication for a
certain period of time.
c) Varios applications have heavy dynamic pages which render significant
amount of data squashing db, wire and CPU. Examples are reports, charts,
etc.
There are other examples, but I expect that these three encompass a
sufficient class of applications which deserve attention if Cocoon is to
claim enterprise level scalability.
>
> 2. pages built dinamically, e.g. from an external news feed, that might
> change everytime but where it's acceptable to assume that it's not
> important to propagate the change to the final user before a given
> timeout. This is IMHO the majority of dynamic pages today. In this case
> having an Expires set might help a lot: consider a site which gets 100
> hits per second, setting an Expires of 5 seconds might alleviate the
> burden on Cocoon by a factor of 500, with two Cocoon served requests
> serving up to 1.000 client requests.
Very good example.
>
> In 1. I don't really see how setting an Expires might help. Or am I
> missing something?
Let me know if I filled the gap?
Cheers,
Ivelin
>
> Ciao,
>
> --
> Gianugo Rabellino
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
