Hi! I'm on a Mac 10.6.2 an I have the same issue here. My test as on WebKit Version 4.0.4 (6531.21.10, r52686).
Using GWT 2.0 and GXT 2.1.0. I think that the problem is the combination of GXT and GWT. I tested my application without Hibernate and it is a little faster, but still very slow. Maybe as GXT is pure JAVA it needs some parse from the GWT, other solutions, like SmartGWT that is just a wrapper it may be faster, I don't know. If I compile my project and run it as javascript it gets stunning fast! Regards, On Jan 12, 8:22 pm, Chris Lowe <[email protected]> wrote: > Hi Tim, > > It's still conceivable for a circular reference (or at least massively > repeated objects) to be at play here. Your response size is 165739 bytes > *compressed* size - many identical objects could compress to something > relatively small and their expansion could cause issues. Also with > Hibernate you most likely won't see a lot of database traffic from repeated > objects as subsequent fetch requests will hit the session's level 1 cache. > > A quicker test could be to temporarily disable gzip encoding in your > browser, for example here are instructions for FireFox: > > http://kb.mozillazine.org/Network.http.accept-encoding > > With gzip disabled, what size response does Jetty report? > > BTW - which browser are you using? > > Cheers, > > Chris. > > <http://kb.mozillazine.org/Network.http.accept-encoding> > > 2010/1/12 Tim Mattison <[email protected]> > > > > > That's what I thought originally but I can see that it's only pulling back > > 165739 bytes from the RPC. When I don't return anything it turns out that > > it runs quickly so it obviously must be related to that. > > > I'm not using DTOs but where is it trying to fetch the data from if it's > > not getting pulled back from the POST? I don't see any traffic to the > > database server so it must be doing something weird locally (like a circular > > reference as you suggested). Shouldn't it give up on circular references a > > bit faster than that if that's the case? > > > Tim > > > On Tue, Jan 12, 2010 at 3:56 PM, Chris Lowe <[email protected]>wrote: > > >> Tim, > > >> Are you filtering your Hibernate objects or translating them to DTOs (to > >> remove dynamic proxies etc) before serialising them? > > >> If the answer is no to the above, then you might be falling foul to > >> circular references or Hibernate fetching more data than you expect. As an > >> experiment, is it possible to try hardcoding some of your objects with a > >> minimal data set and see how your app performs? > > >> Cheers, > > >> Chris. > > >> 2010/1/12 Tim Mattison <[email protected]> > > >>> I changed my debug level from "Info" to "Debug" and got lots of > >>> additional output but nothing that looked like it was the culprit. My > >>> application runs like this: > > >>> 1) onModuleLoad is called, builds the UI, and fires off a GWT-RPC call > > >>> 2) The server receives the GWT-RPC call, connects to a Hibernate > >>> database, pulls some data (~150K) and sends it to the client > > >>> 3) The client receives the response and populates a FlexTable with the > >>> data > > >>> Between 2 and 3 is where the storm of traffic occurs. With the new debug > >>> level I don't really get much more insight since I see that Jetty has sent > >>> the response to the browser and that's it. I have breakpoints set on my > >>> GWT-RPC callback's onFailure and onSuccess method and it doesn't get to > >>> either of those branches until minutes later. Is there somewhere else I > >>> can > >>> look or something else I can try? > > >>> The last message in the log before the storm: > > >>> 200 - POST /app/service (127.0.0.1) 165739 bytes > > >>> Request headers > > >>> Host: localhost:8888 > > >>> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; > >>> rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 > > >>> Accept: > >>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > > >>> Accept-Language: en-us,en;q=0.5 > > >>> Accept-Encoding: gzip,deflate > > >>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > > >>> Keep-Alive: 300 > > >>> Connection: keep-alive > > >>> Cache-Control: no-cache > > >>> Referer:http://localhost:8888/app/hosted.html?app > > >>> X-GWT-Permutation: HostedMode > > >>> X-GWT-Module-Base:http://localhost:8888/app/ > > >>> Content-Type: text/x-gwt-rpc; charset=utf-8 > > >>> Content-Length: 175 > > >>> Pragma: no-cache > > >>> Response headers > > >>> Content-Encoding: gzip > > >>> Content-Length: 165739 > > >>> Content-Type: application/json; charset=utf-8 > > >>> Content-Disposition: attachment > > >>> The first message after it hits onSuccess and then keeps going at a > >>> normal speed: > > >>> 304 - GET /app/gwt/standard/images/hborder.png (127.0.0.1) > > >>> Request headers > > >>> Host: localhost:8888 > > >>> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; > >>> rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 > > >>> Accept: image/png,image/*;q=0.8,*/*;q=0.5 > > >>> Accept-Language: en-us,en;q=0.5 > > >>> Accept-Encoding: gzip,deflate > > >>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > > >>> Keep-Alive: 300 > > >>> Connection: keep-alive > > >>> Referer:http://localhost:8888/app/gwt/standard/standard.css > > >>> If-Modified-Since: Tue, 03 Nov 2009 15:44:06 GMT > > >>> Cache-Control: max-age=0 > > >>> Response headers > > >>> Any help would be great. > > >>> Tim > > >>> On Tue, Jan 12, 2010 at 3:04 PM, Chris Ramsdale > >>> <[email protected]>wrote: > > >>>> Although this smells of a network configuration issue, one suggestion > >>>> you could try is to set the log level to Debug or lower. > > >>>> Debug->Debug Configurations->GWT->Log level. > > >>>> Try that, and let us know if anything suspect is output. > > >>>> - Chris > > >>>> On Mon, Jan 11, 2010 at 11:56 AM, timmattison > >>>> <[email protected]>wrote: > > >>>>> I just started using OOPHM on my Mac (10.6.2) and it is very, very > >>>>> slow. I've tried all of the recommendations about changing the URL to > >>>>> include only "localhost" or "127.0.0.1" but I still have to wait > >>>>> nearly three minutes for my application to start. > > >>>>> The program I'm writing is currently very small and only consists of > >>>>> less than 200 lines of code. It does import a JAR that contains > >>>>> definitions of a lot of objects and has some dependencies (Gilead, > >>>>> Hibernate, GXT) for the server side components but right now I'm just > >>>>> using basic GWT components. Does the size of the dependencies and > >>>>> included JARs matter? > > >>>>> I ask because I notice that as soon as I start the application the > >>>>> traffic on port 9997 to and from my loopback interface is pegged at > >>>>> 1.5MB/sec in each direction for the entire three minutes the > >>>>> application is starting up. I stepped through my code with a debugger > >>>>> and the client side code gets set up, runs, then there's a three > >>>>> minute pause where all of this data goes back and forth, and then the > >>>>> server-side code runs. The client and server side code takes less > >>>>> than 1 second to finish so I don't think it's a bug in my code. > > >>>>> I tried to capture the traffic in Wireshark to figure out what is > >>>>> getting sent but it looks like all of the packets are very small (~56 > >>>>> bytes) and trying to capture the whole session causes Wireshark to > >>>>> crash. > > >>>>> Is anyone else seeing this loopback traffic problem? I assumed maybe > >>>>> the debugger is communicating my dependencies to the OOPHM plugin but > >>>>> my dependencies are nowhere near this large. > > >>>>> What other information can I provide to help this get debugged? > > >>>>> Thanks, > >>>>> Tim Mattison > > >>>>> -- > >>>>> You received this message because you are subscribed to the Google > >>>>> Groups "Google Web Toolkit" group. > >>>>> To post to this group, send email to > >>>>> [email protected]. > >>>>> To unsubscribe from this group, send email to > >>>>> [email protected]<google-web-toolkit%2Bunsubs > >>>>> [email protected]> > >>>>> . > >>>>> 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 > >>>> [email protected]. > >>>> To unsubscribe from this group, send email to > >>>> [email protected]<google-web-toolkit%2Bunsubs > >>>> [email protected]> > >>>> . > >>>> 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 [email protected] > >>> . > >>> To unsubscribe from this group, send email to > >>> [email protected]<google-web-toolkit%2Bunsubs > >>> [email protected]> > >>> . > >>> 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 [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<google-web-toolkit%2Bunsubs > >> [email protected]> > >> . > >> 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 [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<google-web-toolkit%2Bunsubs > > [email protected]> > > . > > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
