tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mosiewicz <m...@interdata.com.pl>
Subject Re: Discussion: AJP next
Date Sat, 12 Feb 2000 23:54:31 GMT
costin@eng.sun.com wrote:
> [...]
> 1. If a response _does_ set expire headers, it should be easy to cache it
> on apache side, either in memory or in file system. ( similar with using a
> squid accelerator). We don't need any API, just an apache module ( that
> can be used for CGIs for example ). It would be really _cool_.

But you are talking about the whole response, while I'm talking about
fragments. To get the idea, just take a look at some larger portal site
- you've got several common elements, like w3 catalogs, stock indexes,
latest news, and finally - some advertising. Usually you can cache those
elements with different expiration times - for example hours for w3
catalog is usually fine, latest news may be delayed by minutes, stock
indexes by seconds or minutes. Ads cannot be cached at all, cause you
will usually need some personal profiling methods to serve them. So -
the common denominator for the whole page is not to cache it at all,
becouse it is partially served on a per-user basis.

> 2. For JSPs we have a great advantage - we know that a portion of the page
> is constant. ( as a matter of fact, it's one of the main reasons I like
> JSPs ! ). It is very easy to mark the constant body.
> 
> In API terms, the response from tomcat will consist in fragements. Because
> of  the 2.2 buffering we already have that implemented, and that might
> help a lot in another area ( HTTP/1.1 and HTTP connection reuse ).

That also could help in lowering communication costs. Sometimes it
appears to be very easy to push 10kB response in one tcp packet that is
fraction of that size. 

Mike

Mime
View raw message