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