[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