Chris Lowe wrote: [...] > 500-600 does seem like a lot of objects to be processing in one hit if > performance on a low end server is a concern, but then again 20 > seconds seems like an awfully long time too.
Actually, thinking about it, it's more than that --- probably around 1500 objects (500 large objects, but each one contains references to a few small just-data objects). > What's the performance like in your dev environment? Are your JVM > settings the same as those on your target server? [...] > You can also add a simple filter before the GWT servlet to > give you a very coarse request timing - you can at least then rule out > latencies and bandwidth to your server. I wish. The target server is a solid-state ARM box -- a SheevaPlug (1.2GHz processor, 512MB RAM). Alas, there is no decent JIT for ARM yet, so it's running the interpreted JDK. I'll check out VisualVM, but I suspect that it's not up to running it. Annoyingly the machine is perfectly capable of running the actual *application*. The actual logic takes a tiny fraction of the time of the serialisation. My development machine is a traditional ix32 box and serialisation takes a trivial amount of time. I'll try the trick with the filter to get some actual figures. [...] > How large are your serialized objects prior to compression? I think > you can quickly test this by disabling gzip compression in FireFox: > > http://forgetmenotes.blogspot.com/2009/05/how-to-disable-gzip-compression-in.html This just causes the page to turn into garbage --- probably a server misconfiguration on my end. > If the uncompressed size is particularly large then memory and > compression time may be the limiting factor. Looking at the server stats its VM size doesn't appear to change during the first serialisation process, indicating that it doesn't want to allocate more memory. I have a feeling that memory's not the problem. > Finally, what kind of objects are you serialising? Are you attempting > to send something like Hibernate objects over the wire (or some other > kind of proxied objects) which are causing unexpected database hits? Nope. The entire DB is being held in-memory. In fact, the way my app works is that the server logic calculates the delta needed to be sent to the client, constructs a packet of client objects from this, and then returns that packet as the result from the RPC call, so the stuff being serialised doesn't actually content to the objects in the DB at all. (My 400-object delta, the result of the initial DB sync, takes about 4s to generate.) The delta generation uses reflection and annotations to query the DB objects for properties that need to be copied into the delta. (The client is only allowed to see information from the DB that the user is allowed to have.) Simply by adding a cache for Field objects I managed to reduce the time taken for the delta generation by a factor of ten, so I suspect that reflection is dog slow with this JVM. What does the GWT serialisation system use? If it uses reflection, is there any way of persuading it to use byte-code generation instead? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "They laughed at Newton. They laughed at Einstein. Of course, they │ also laughed at Bozo the Clown." --- Carl Sagan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
