17 Jul 2009 4:35 AM #1
How to improve RPC performance
How to improve RPC performance
I am working on big project in which I am using many components of EXT-GWT. All are working fine but my main concern in speed.
In my application,
1. I have one module in which I am using TreeTable component. Now, when I open this module it will make RPC call to server.
2. At server side, I have code in hibernate which will fetch data from database, create one POJO class for one record and finally return List of POJOs to client ( 100 POJOs - It will increase in future).
3. At client side, these data will be set in TreeTable component.
All the above steps client->server->client are taking 14-15 sec. to complete.
It is taking 8-9 sec. to return List of POJOs from server to client back and 4-5 sec. to set returned List of POJOs to TreeTable.
Is there any way to improve performance of RPC so I can get data within 2-3 sec.
Hope, I am clear to you. Please give me suggestions or guidance to achieve speed.
17 Jul 2009 4:38 AM #2
For the TreeTable rendering: TreeTable is not the fastest one. That is why we replaced it with the TreeGrid. I suggest to change to the TreeGrid.
RPC calls should not take 5 secs for only 100 objects. Is it possible that this objects have many inner objects or big lists?
17 Jul 2009 4:48 AM #3
Thanks for your quick reply
Yes ideally it should not take but it is taking and I don't have other object or list in it.
But, how to deal with it if I have reference of other object in it?
How many changes do I need to migrate from TreeTable to TreeGrid?
21 Jul 2009 2:05 AM #4
21 Jul 2009 8:09 PM #5
Wow those are some pretty slow timings..... I do not use RPC, I use Restful WebServices (basically Servlets in Jersey) and output JSON. My web services access my JPA backing store using EclipseLink. So similiar except I am using RequestBuilder to do my AJAX call and I am responsible for converting my POJO to JSON.
On startup I need to load ~ 5 stores (key preferences, albums, collections, countries and catalogues) and it does so in an aggregated 1.5 seconds of "network" time. (I have 98 countries, the others are typically 10 or less). This is browser request/response AJAX time. Time to render these is negligble (only the TreePanel takes any time and it builds remarkably fast compared to the old Tree widget). It took 500-700 milliseconds to recieve 50 objects / page upon choosing a filter and the "render" time is probably < 1.0 second to render the grid (50 rows with 8 columns). I should also mention, the objects in this table are not a simple bean but have relationships to other beans as well as foreign references and these are needed to render some of the columns (for example the bean contains the country id as a foreign key, and the country name comes from the country store loaded at startup) Generally speaking, parsing the JSON into beans is the slowest part but if you are using Chrome, Firefox 3.5 or even IE8 this is faster (Chrome is lightening fast!) If I turn off paging and download all 1000 objects for one grid "view", the objects are downloaded in ~ 2.0 seconds and the display will take longer (as long as 25 seconds on IE7 - I think it was something like 7-8 seconds in Firefox 3.0). This is part of the reason for the switch the paging. The disadvantage for me right now, is because many of my columns do not have a natural sort order, I need to server sort where I have this logic already coded. But even this I did a few things like request the next page upon completion of the current page to cache so that I have it ready for the next request, things like that.
My app is small (datawise) only because it is dependent on my entering more of the data, but I have approximately 7000 items I will display to the user (in a few panels) etc. and rarely is there ever more than a 2.0 sec delay for anything (this is accessing my server in my basement over a cable modem from a remote location) If you really have to display a "report" of stuff (trust me I understand - I develop PDM systems in my day job! Try displaying the product structure for an aircraft) You'll need to squeeze every last CPU cycle and try and push the penalty to the client browser (ie. get a faster machine = faster display). If you are working on a little more mundane client, then try and think of ways to do more and display less (ie. paging, scrolling tables, don't get a tree store and then make a query for N stores representing the types in the tree etc.)
21 Jul 2009 8:40 PM #6
My limitation is that I have to use only GWT-RPC to retrieve data from server and I am returning List of POJOs from server.
So, is there any way to improve performace of GWT-RPC? I want to return List of POJOs only so I can't use JSON.
23 Jul 2009 12:37 PM #7
Take a look in Firebug to see how big the actual size of the transfer is - a page I am working on pulls down and deals with 13k of objects in just over two seconds, and renders all of the data in about another two.
As Sven asked, are there a lot of other objects that each of those 100 objects has as properties? And can you switch to some other display than a TreeTable?
23 Jul 2009 9:00 PM #8
It is only 3935 means 3kb.
I surprised why it is taking time for such small data.
Can you provide any comments or suggestion in this?
it is not feasible to shift from TreeTable to other component say TreeGrid.
I have done certain R&D on TreeGrid and came on conclusion that
I need to change code and flow to shift to TreeGrid and
my project is little bit typical so it might be possible that it will create
some more bugs.
24 Jul 2009 8:42 AM #9
3k is nothing - the delay you are experiencing is your js processing and rendering. If you aren't willing to change your code, then there isn't much else I can suggest that you do... Slow UI code is slow, and superficial changes cannot fix that.
26 Jul 2009 10:17 PM #10
But I have noticed time when server call happened and time when I got complete list of POJOs from the server. The difference between these two times show me that this server call is taking 10-12 seconds. After it data rendering comes in pictures in which js comes in pictures.