Re: OOPHM is slow
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 <chris.lowe...@gmail.com> 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 <timmatti...@gmail.com>
>
>
>
> > 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 <chris.lowe...@gmail.com>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 <timmatti...@gmail.com>
>
> >>> 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 <cramsd...@google.com>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 <timmatti...@gmail.com>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
> >>>>> google-web-toolkit@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubs cribe@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-toolkit@googlegroups.com.
> >>>> To unsubscribe from this group, send email to
> >>>> google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubs cribe@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-toolkit@googlegroups.com
> >>> .
> >>> To unsubscribe from this group, send email to
> >>> google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubs cribe@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-toolkit@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubs cribe@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-toolkit@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubs cribe@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/google-web-toolkit?hl=en.
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home