Re: Caching Static Items

Anthony Eden <[email protected]> Fri, 28 Feb 2003 10:35:16 -0500
Newsgroups gmane.comp.java.jpublish.devel
Message-ID <[email protected]>

Florian Gnägi wrote:
> Hi Anthony
> 
> Another isse with the static resource loader is the fact that all static files won't have a 
> correct HTTP header field "Last-Modified". This causes the browser to fetch all static resources 
> every time over and over again even if it is not necessary at all. This means if a site is slow 
> and uses a lot of images in the layout it is probably due to this problem with the static resources 
> and how they get served in jPublish.

I agree that this is probably the biggest performance problem in JPublish right now.  I am working towards a unified Repository system for all resources in JPublish.  If this were in place it would be possible to get use the Last-Modified header if the resource is loaded from a system which maintains the last modified time.

> The root problem is that the resource manager uses streams and therefore can't say anything about 
> the last modified date of a resource and does not set the propriate header field. 

Right, and this would be fixed with a unified repository system because all content would have meta data associated with it.  This is just one more step towards JPublish becoming more CMS-like.

> Below is our hack of the jPublishServlet that eliminates this problem. This is using jPublish 1.4 and 
> not 2.0, I don't know if this problem is solved in the 2.0 version.

It is not solved yet, but I will try to put in a fix.

> Another 'Problem' with the static resources is also that we would like to have something that can 
> serve static resources without any jPublish activity, just raw file delivery, no actions, nothing. 
> E.g. for images. Of course one can server the images by an apache server, but still it would make 
> sense to me to have a static resource construct that has no jPublish overhead at all. Right now 
> jPublish is doing quite some stuff like context generation, path actions, pre/post actions, error 
> handling etc. that is absolutely unnecessary for delivering unprotected static content like a 
> navigation image. 

Right.  At the same time it is sometimes useful to do processing even when something is "static".  So how to differentiate between the two?

> I'm very curious on the upcoming 2.0 release and  how the caching of pages you mentioned earlier 
> this week improves the performance!

Personally I think it will provide only small gains, but we'll see.  Perhaps the real gain will come when dealing with a very large number of requests.

> Best Regards & a nice weekend!

Same to you.

Sincerely,
Anthony Eden



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf