[seam-dev] Caching of Seam Remoting Interface Components

[Dan Allen]

On Thu, Jun 25, 2009 at 3:42 PM, Ashish Tonse <ashish.tonse at gmail.com>wrote:

>
>   I am currently working on implementing Seam on part of a relatively high
> traffic site (8k+ concurrent users) and optimizing our backend and frontend
> to handle that traffic. When focusing on front-end, I'm trying to make sure
> that the right HTTP caching headers are sent out -- but our Seam Remoting
> javascript files can't be browser-cached for a couple of reasons:
>
>   /interface.js?componentName won't get cached due to it containing a query
> string and the way browsers handle those
>   /remote.js always returns an HTTP 200 with the actual file contents,
> whereas this file would only change with new Seam releases (is that
> correct?)
>
>   Also, neither of these JS files are combined, packed or minified.
>

Yep, you have identified one of the key optimizations that really needs to
be addressed in Seam.


>
>   The Seam Remoting InterfaceGenerator does have an interface cache for
> each component, so at least that time is saved. But it still sends back
> unnecessary unchanged content to the browser. Since javascript downloads
> block all other downloads in the browser, this is especially noticeable with
> load times, making the page seem slower.
>
>   A good potential solution (suggested by Dan Allen on twitter) to the
> first issue... use the ReWrite filter. My guess would be something like
> this:
>
>   /interface/componentName.js --> interface.js?componentName
>
>   And if we sent the right HTTP caching headers, that would fix that issue
> and browsers could cache it. But what about using multiple components? This
> is what I propose...
>
>   /interface/componentName1,componentName2,componentName3.js ----->
> /interface.js?componentName1,componentName2,componentName3
>

Why not go with something a little more natural? Such as:

/seam/resource/componentName1/componentName2/componentName3/interface.js

I wonder if the extension is even necessary since the servlet is being
matched using the /seam/resource/* pattern.

Christian and Jozef, any thoughts on the URL design here?



>
>   Is this something reasonable enough that I can take on as my first Seam contribution? (Seems
> small enough)...
>

Sure thing. You have to start somewhere, right?


>   Furthermore, in non-debug mode, Seam should send back minified Javascript
> (using the Java based YUI-compressor)
>

Absolutely.

-Dan

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20090625/828bb981/attachment.html