[seam-dev] Caching of Seam Remoting Interface Components

Pete Muir pmuir at redhat.com
Thu Jun 25 16:35:21 EDT 2009


On 25 Jun 2009, at 21:16, Dan Allen wrote:

> 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

This isn't right, as it implies hierarchy where there isn't any  
(component 2 isn't a child of component1). You should use either a  
command or a semi-colon - the general recommendation is to use a comma  
if the order is important, semi-colon if it isn't (it isn't here).

I would suggest /interface.js/component1;component2 etc.

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

Yes, keep it, as it adds information to the URL.

>
> 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.

Make sure this is optional :-) Not everyone wants to be forced to add  
this dependency.

So, if YUI-compressor is available AND not in debug mode...

>
> -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.
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev




More information about the seam-dev mailing list