Sripathi, Thanks for the comments. I am not familiar with Google Wave, but I will look at it to see how Google Wave can solve this problem easier.
Yes, for this round, I do combine 1) and 2) and use Akamai edge cache. That will 1) reduce the traffic to our app server, 2) enable the user to get response quickly from near by Akamai edge server. I will see the result before approaching combination of the step 3. Later on, I more like to use Google App engine to serve the user request. On May 16, 1:31 pm, Sripathi Krishnan <sripathi.krish...@gmail.com> wrote: > You are essentially including the content of nocache.js in the host html > file, and therefore combine (1) and (2) in your original question. This > works, and as Thomas pointed in this > post<http://groups.google.com/group/google-web-toolkit/msg/9676c52a34a064c6>, > its what google wave does. > > But you DON'T want to combine step 3. You lose the ability to set aggressive > cache headers. Besides, the same URL will return different content based on > the browser - so you'd have to do some weird Akamai configuration. You can > set the Vary : User Agent header - but that would give even worse > performance, because the 6 supported browsers have thousands of user-agent > variations. > > --Sri > > On 16 May 2010 22:31, Michael W <mwang_2...@yahoo.com> wrote: > > > > > I provide a work around to load nocache.js on the first request. > > See enhancement of > >http://code.google.com/p/google-web-toolkit/issues/detail?id=4948 > > > It will satisfy our needs currently as we use Akamai edge server to > > cache .the cache files (user gets cache file from nearest server of > > Akamai ) > > > On May 8, 1:53 pm, Michael W <mwang_2...@yahoo.com> wrote: > > > Thank for the response of Sripathi and Chris, > > > > We have used firebug page speed, YSlow and Chrome Speed Tracer, GWT > > > debug panel. > > > > Few changed already applied and few are in the pipeline > > > > The actions have been done so far for the performance: > > > 1. Used Akamai.com content cache implementation to cache the result of > > > RPC, images, Jascript and css files, so the user can get content from > > > nearest Akamai servers. > > > 2. Group bunch of third party Javascript(s) into one server call. > > > 3. Bind several requests into one RPC call (dayContentService.rpc) > > > 4. Multi thread in server side to fetch result for > > > dayContentService.rpc > > > 5. Changed the execution flow to load/execute GWT module first and > > > then load/execure third party Javascript(s) > > > 6. Applied ClientBundle for the images loaded from GWT module. (you > > > can see it from logo, calendar, Find The Hotel images) > > > 7. Defer to load Google map key on demand > > > 8. Code splitting to reduce home page size. > > > 9. Gzip the response. > > > > Changes in the pipeline: > > > 1, Like Sripathi point it out, we will add expires header to images > > > (most images coming from the result of RPC, so it is hard for us to > > > use ClientBundle with GWT) > > > 2. Add additional image domain for browser to parallel to load images. > > > Current we only have image3, we will add image4. > > > > The website serves the user around the global, the challenge we are > > > facing with: > > > Most user's response time is fine, but some complain that the site is > > > slow. Some region such as China reports that the page is slow to > > > download. > > > > That is the main reason I start to look at the initial load. > > > > Chris, > > > I am interesting in the 'server-side selection' approach. Let me know > > > if you have any new progress on it. > > > > I am also thinking to use App engine to load GWT module, so user can > > > get initial load from the server near by. As far as you know, does > > > anyone successfully use App engine to load GWT. > > > > On May 7, 6:47 pm, Chris Conroy <con...@google.com> wrote: > > > > > On Thu, May 6, 2010 at 11:05 PM, Sripathi Krishnan > > > > > <sripathikrish...@gmail.com> wrote: > > > > >> Technically, in the very first request, the server already knows > > user > > > > >> browsers' type, is that feasible to: > > > > >> combine 1), 2) and 3) together or > > > > >> combine 1) and 2) together or > > > > >> some other consideration > > > > > > You are right, this is possible. See this discussion thread - > > >http://groups.google.com/group/google-web-toolkit/browse_thread/threa... > > > > > > But, before going down that optimization path, there are several > > other > > > > > low-hanging-fruits to speed up your website. I looked at your website > > via > > > > > firebug, and the following issues come to my mind - > > > > > > *.cache.xxx file don't have a 'far into the future' expires header. > > > > > Several (30 or so) images get downloaded at startup. None of these > > images > > > > > have aggressive cache settings. You are not using GWTs ImageBundles > > to > > > > > potentially inline these images. > > > > > You have atleast 2 RPC calls at startup (getDayContent and > > > > > getTargettedContent).The response of these calls is known ahead of > > time > > > > > (since they don't depend on any user input), and hence you could > > potentially > > > > > inline their response in the html and then use a Dictionary to read > > it in > > > > > onModuleLoad. Or you could use a ClientBundle to compile the data > > with your > > > > > application. Either way, you save two important 'pseudo-asnyc' > > requests that > > > > > delay initial rendering of your application. > > > > > I see you have a custom implementation to trace performance events. > > Have you > > > > > taken a look at GWTs Lightweight Metrics? > > > > > > --Sri > > > > > > On 7 May 2010 02:21, Michael W <mwang_2...@yahoo.com> wrote: > > > > > >> We launched our GWT production ofhttp://www.holidayinn.comfewmonths > > > > >> ago and we are in the phrase to tune the performance. > > > > > >> We see quick high percentage of traffics coming from nocach.js and > > > > >> cache.html, and just thinking how to reduce over all traffics. > > > > > >> The normal flow of GWT would be like followings: > > > > >> 1) The user request the website, the first server call is to > > get > > > > >> generated html file (from JSP/Servlet) > > > > >> 2) Then browser sends second request to fetch nocach.js with > > > > >> <script type="text/javascript" language="javascript" src="/ > > > > >> directory/xyz.nocache.js"></script> > > > > >> 3) Based on the user browser's type, the browser send third > > request > > > > >> to > > > > >> get .cache.html > > > > >> 4) Few RPC calls to get real content. > > > > > >> So at least three requests are executed in sequence before the user > > > > >> can see something. It is kind of expensive. > > > > > >> Technically, in the very first request, the server already knows > > user > > > > >> browsers' type, is that feasible to: > > > > >> combine 1), 2) and 3) together or > > > > >> combine 1) and 2) together or > > > > >> some other consideration > > > > > >> Would like to hear your opinions. > > > > > >> Thanks > > > > > >> --Michael > > > > > Michael, > > > > > You may find it easier to analyze performance issues in your app using > > > > SpeedTracer: > >http://code.google.com/webtoolkit/speedtracer/get-started.html > > > > > (You are correct that you can eliminate that initial round trip by > > > > doing the selection on the server. We refer to this as 'server-side > > > > selection'. Unfortunately it is not yet part of GWT proper) > > > > > -- > > > > Chris Conroy > > > > Software Engineer > > > > Google, Atlanta > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups "Google Web Toolkit" group. > > > > To post to this group, send email to > > google-web-tool...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > > . > > > > For more options, visit this group athttp:// > > groups.google.com/group/google-web-toolkit?hl=en. > > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > > To post to this group, send email to google-web-toolkit@googlegroups.com > > . > > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > > . > > > For more options, visit this group athttp:// > > groups.google.com/group/google-web-toolkit?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to google-web-tool...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
