Re: RPC Performance/Response Problem
Hi Jason, thank you for your answer, you (and gregor) were absolutely right: Hosted mode isn't useful to test the app if you want to know how it REALLY works later on. I've tried it in web mode now, and it seems as if this solves my problem completely. These 5 seconds are reduced to practically 0s. I think my data sets are not that big (talking about 5000 Strings in an array). Since the web mode seems to solve my problem i will contine to program the functional part of my app and see how it works later on. If i will get the same problem in web mode i will try RequestBuilder. Thanks for the hint. TO EVERYONE WHO READ THIS THREAD AND HAS THIS PROBLEM: TEST YOUR APP IN WEB MODE. Thanks to everyone for the help. Really nice work here! Greetings, -Lord-67 On Mar 27, 8:37 pm, Jason Essington jason.essing...@gmail.com wrote: Hosted mode isn't particularly useful in determining how things will actually perform in real life. It is useful for debugging, but the performance of certain operations tend to vary drastically from web mode. So, if you are testing your performance, you'll want to do it in web mode. As for using large data sets, best to avoid that if you can. But there is a trick you can use if you determine that de-serialization on the client is your bottleneck. Rather than use GWT-RPC, you can use RequestBuilder to make the request, and simply return raw JSON data. On the client side you can use Javascript overlay types and simply eval() the result into an object. With very large data sets this technique can be orders of magnitude faster than regular RPC de- serialization. Another trick that might be useful would be to inject the JSON results into the host page, so that a second request isn't even required, then you can still use overlay types to access that data. -jason On Mar 27, 2009, at 8:43 AM, -Lord-67 wrote: Hi gregor, thank you for this detailed answer. First: I'm not sure if i understood everything since english is not my first language as you might have noticed. Sorry if i misunderstood something, i do my best. You're right what belongs the selection of data structure. I tried that and it makes no difference using a String[] or a ListArray of Strings to use as return value for the RPC. I know that rendering thousands of items takes some time, but that's not what i do with the data. I already use a model like you described in FastTree. I just fetch all the data (in my case paths to images in a String[]) from the server via RPC and show the user just 10-50 pictures per page. I create only 10 images (100px*100px) + a paging menu (first tab) and 2 tables(grids with fix size) (second, third tab). In my opinion rendering these few items (say max. 50) is not the problem, right? The kind of model you described as LazyLoad is something i also thought of, but i liked the idea of waiting one time for about 3 seconds and working on this set without having to wait any more (this is what my users would like most). That's why i haven't tried it so far. I already measured the RPC call round trip time, think i haven't said that clearly enough in my first post: - Starting the RPC (sending search parameters via RPC to the server): (no time i could measure in ms - 0ms) - server gets data per SQL statement and puts it into a String[] (the return value of the RPC): This step takes less than 200 ms [i measured the time from the start of RPC on server until the last statement, before return myStringArray; ] - server serializes the data and sends it to client which deserializes it: This step takes about 5 SECONDS [i measured the time from sending the RPC to the server until i got the first answer on the client with onSuccess() and substracted the 200ms ] - client saves the data in a lokal String[] and uses some of them to load and render 10 pictures and 2 tables: This step takes 1.2 seconds [i measured the time from onSuccess() beginning to the end ] So i am no step forward so far, but: I think i didn't test it in web mode for a long time (why should i, everything was fine on hosted and on web mode in the beginning and hosted mode is much easier for a quick test) so i will try that and hope it solves the problem. I will tell you the results on monday since i am not working the next two days. Thanks all for the help so far! Greetings, -Lord-67 On Mar 27, 2:00 pm, gregor greg.power...@googlemail.com wrote: Hi Lord-67 I don't think your selection of data structure for the data transfer will make nuch material difference. Your observation that 500 strings works hunky dory, but 10,000 doesn't is pretty much my experience. The issue is divided into two parts: first the time taken to assemble, serialize and then deserialze the List of objects. Second the time taken to render the objects in a widget. You may not know this but it takes browsers an appreciable amount of
Re: RPC Performance/Response Problem
No, i haven't tried that so far, i will do so and let you know if it's getting better. Maybe a List needs less time to be serialized and deserialized. Greetings, -Lord-67 On Mar 26, 6:27 pm, lukehashj bobwazn...@gmail.com wrote: Have you tried using a List instead of an array? On Mar 26, 2:46 am, -Lord-67 -lord...@web.de wrote: First of all: Hi to everyone! I'm new to GWT and just programming my first app. Since i've some experience in Java it's not a big problem, but in this case i am stuck and hopefully someone can help me. In my app i make a RPC: On server side i get some data out of a database and save it into an array of type String. Up to 10.000 Strings atm, later on maybe up to 50.000. It is no problem so far. The server is handling this really fast. I measured 5 RPCs with about 500 Strings each and it took less time than 200 milliseconds each (SQL Statement + creating the array). The problem now is: I have to wait 5 SECONDS to get the results of the RPC (the String[] created on the server) on the client side so i can do something with them. Regarding the overall time i measured, these 5 seconds are more than 75% of the time which my app needs. Is it possible that the serialization and deserialization takes that much time? I don't think so and i have no clue where this 5 seconds come from. If someone has any ideas, solutions, suggestions on this problem i would appreciate any help! Thanks in advance, -Lord-67 P.s.: Of course i searched for a solution for this problem for hours, if i somehow just typed the wrong keywords to get the fitting results, just let me know and post a link :-). --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: RPC Performance/Response Problem
Hi Lord-67 I don't think your selection of data structure for the data transfer will make nuch material difference. Your observation that 500 strings works hunky dory, but 10,000 doesn't is pretty much my experience. The issue is divided into two parts: first the time taken to assemble, serialize and then deserialze the List of objects. Second the time taken to render the objects in a widget. You may not know this but it takes browsers an appreciable amount of time to render thousands of items - each one has to have a number of HTML boxes drawn for it. Test this yourself by making a simple test Tree created from some nested for loops on the client, and you will see that once you get up to 1500 or so TreeItems it starts to slow down noticably, and round about 5000 it takes seconds to draw. Note also different browsers give different performance in some situations, so you need to consider that too. Another important thing is that RPC is *much* slower in hosted mode than it is deployed in web mode (in case you haven't rumbled that yet). You can try two approaches to solve this: the classic lazy load, and the FastTree approach. In the lazy load approach you fetch only a screen full of items at a time (in a tree you would get just the top level items etc). next link fetches the next batch. This usually produces a response time from the user's perspective of 0.5s, which for them is a good as instant. Therefore although technically each page flip is slow (involving a fresh RPC call for each page) it is not perceived as such, the user does not have to wait seconds for the data to load. In the fast tree approach you fetch all the data in one RPC call, but only actually draw screen full at a time, using the full list as a backing model instead of making a fresh RPC call for each page. This makes navigating the items in the UI very fast once the data model is loaded because only the visible HTML boxes required are actually drawn, but you pay a pre-loading price up front in the big RPC call. Which is best depends largely on your application and user requirements and also on the precise time it takes to fetch the entire list over RPC. For example if your users will routinely want to sort, filter or search through a large data set in complex ways, then they will probably thank you for implementing the fast tree idea and be happy to wait maybe 2 or 3 seconds to fetch the all data up front because the subsequent operations will be much faster. On the other hand if a 1 item list is unusual, or they would normally only be interested in first page of two (typical for search results for example) then the classic lazy load is almost certainly best as it gives them a much quicker render of the first screen full. I'd say the first thing to do is to is to time your RPC call round trip separately from your screen render times to get a feel for the numbers, but do this in web mode either over web or on LAN, whichever is appropriate for your typical user, in a selection of popular browsers. regards gregor On Mar 27, 10:35 am, -Lord-67 -lord...@web.de wrote: No, i haven't tried that so far, i will do so and let you know if it's getting better. Maybe a List needs less time to be serialized and deserialized. Greetings, -Lord-67 On Mar 26, 6:27 pm, lukehashj bobwazn...@gmail.com wrote: Have you tried using a List instead of an array? On Mar 26, 2:46 am, -Lord-67 -lord...@web.de wrote: First of all: Hi to everyone! I'm new to GWT and just programming my first app. Since i've some experience in Java it's not a big problem, but in this case i am stuck and hopefully someone can help me. In my app i make a RPC: On server side i get some data out of a database and save it into an array of type String. Up to 10.000 Strings atm, later on maybe up to 50.000. It is no problem so far. The server is handling this really fast. I measured 5 RPCs with about 500 Strings each and it took less time than 200 milliseconds each (SQL Statement + creating the array). The problem now is: I have to wait 5 SECONDS to get the results of the RPC (the String[] created on the server) on the client side so i can do something with them. Regarding the overall time i measured, these 5 seconds are more than 75% of the time which my app needs. Is it possible that the serialization and deserialization takes that much time? I don't think so and i have no clue where this 5 seconds come from. If someone has any ideas, solutions, suggestions on this problem i would appreciate any help! Thanks in advance, -Lord-67 P.s.: Of course i searched for a solution for this problem for hours, if i somehow just typed the wrong keywords to get the fitting results, just let me know and post a link :-). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send
Re: RPC Performance/Response Problem
Hi gregor, thank you for this detailed answer. First: I'm not sure if i understood everything since english is not my first language as you might have noticed. Sorry if i misunderstood something, i do my best. You're right what belongs the selection of data structure. I tried that and it makes no difference using a String[] or a ListArray of Strings to use as return value for the RPC. I know that rendering thousands of items takes some time, but that's not what i do with the data. I already use a model like you described in FastTree. I just fetch all the data (in my case paths to images in a String[]) from the server via RPC and show the user just 10-50 pictures per page. I create only 10 images (100px*100px) + a paging menu (first tab) and 2 tables(grids with fix size) (second, third tab). In my opinion rendering these few items (say max. 50) is not the problem, right? The kind of model you described as LazyLoad is something i also thought of, but i liked the idea of waiting one time for about 3 seconds and working on this set without having to wait any more (this is what my users would like most). That's why i haven't tried it so far. I already measured the RPC call round trip time, think i haven't said that clearly enough in my first post: - Starting the RPC (sending search parameters via RPC to the server): (no time i could measure in ms - 0ms) - server gets data per SQL statement and puts it into a String[] (the return value of the RPC): This step takes less than 200 ms [i measured the time from the start of RPC on server until the last statement, before return myStringArray; ] - server serializes the data and sends it to client which deserializes it: This step takes about 5 SECONDS [i measured the time from sending the RPC to the server until i got the first answer on the client with onSuccess() and substracted the 200ms ] - client saves the data in a lokal String[] and uses some of them to load and render 10 pictures and 2 tables: This step takes 1.2 seconds [i measured the time from onSuccess() beginning to the end ] So i am no step forward so far, but: I think i didn't test it in web mode for a long time (why should i, everything was fine on hosted and on web mode in the beginning and hosted mode is much easier for a quick test) so i will try that and hope it solves the problem. I will tell you the results on monday since i am not working the next two days. Thanks all for the help so far! Greetings, -Lord-67 On Mar 27, 2:00 pm, gregor greg.power...@googlemail.com wrote: Hi Lord-67 I don't think your selection of data structure for the data transfer will make nuch material difference. Your observation that 500 strings works hunky dory, but 10,000 doesn't is pretty much my experience. The issue is divided into two parts: first the time taken to assemble, serialize and then deserialze the List of objects. Second the time taken to render the objects in a widget. You may not know this but it takes browsers an appreciable amount of time to render thousands of items - each one has to have a number of HTML boxes drawn for it. Test this yourself by making a simple test Tree created from some nested for loops on the client, and you will see that once you get up to 1500 or so TreeItems it starts to slow down noticably, and round about 5000 it takes seconds to draw. Note also different browsers give different performance in some situations, so you need to consider that too. Another important thing is that RPC is *much* slower in hosted mode than it is deployed in web mode (in case you haven't rumbled that yet). You can try two approaches to solve this: the classic lazy load, and the FastTree approach. In the lazy load approach you fetch only a screen full of items at a time (in a tree you would get just the top level items etc). next link fetches the next batch. This usually produces a response time from the user's perspective of 0.5s, which for them is a good as instant. Therefore although technically each page flip is slow (involving a fresh RPC call for each page) it is not perceived as such, the user does not have to wait seconds for the data to load. In the fast tree approach you fetch all the data in one RPC call, but only actually draw screen full at a time, using the full list as a backing model instead of making a fresh RPC call for each page. This makes navigating the items in the UI very fast once the data model is loaded because only the visible HTML boxes required are actually drawn, but you pay a pre-loading price up front in the big RPC call. Which is best depends largely on your application and user requirements and also on the precise time it takes to fetch the entire list over RPC. For example if your users will routinely want to sort, filter or search through a large data set in complex ways, then they will probably thank you for implementing the fast tree idea and be happy to wait maybe 2 or 3 seconds to fetch the all data up
Re: RPC Performance/Response Problem
On 26 mar, 09:46, -Lord-67 -lord...@web.de wrote: First of all: Hi to everyone! I'm new to GWT and just programming my first app. Since i've some experience in Java it's not a big problem, but in this case i am stuck and hopefully someone can help me. In my app i make a RPC: On server side i get some data out of a database and save it into an array of type String. Up to 10.000 Strings atm, later on maybe up to 50.000. It is no problem so far. The server is handling this really fast. I measured 5 RPCs with about 500 Strings each and it took less time than 200 milliseconds each (SQL Statement + creating the array). The problem now is: I have to wait 5 SECONDS to get the results of the RPC (the String[] created on the server) on the client side so i can do something with them. Regarding the overall time i measured, these 5 seconds are more than 75% of the time which my app needs. Is it possible that the serialization and deserialization takes that much time? I don't think so and i have no clue where this 5 seconds come from. If someone has any ideas, solutions, suggestions on this problem i would appreciate any help! Short answer: do not use GWT-RPC to transport a large amount of data. Longer answer: http://blog.flickr.net/en/2009/03/17/find-people-faster/ HTH --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
RPC Performance/Response Problem
First of all: Hi to everyone! I'm new to GWT and just programming my first app. Since i've some experience in Java it's not a big problem, but in this case i am stuck and hopefully someone can help me. In my app i make a RPC: On server side i get some data out of a database and save it into an array of type String. Up to 10.000 Strings atm, later on maybe up to 50.000. It is no problem so far. The server is handling this really fast. I measured 5 RPCs with about 500 Strings each and it took less time than 200 milliseconds each (SQL Statement + creating the array). The problem now is: I have to wait 5 SECONDS to get the results of the RPC (the String[] created on the server) on the client side so i can do something with them. Regarding the overall time i measured, these 5 seconds are more than 75% of the time which my app needs. Is it possible that the serialization and deserialization takes that much time? I don't think so and i have no clue where this 5 seconds come from. If someone has any ideas, solutions, suggestions on this problem i would appreciate any help! Thanks in advance, -Lord-67 P.s.: Of course i searched for a solution for this problem for hours, if i somehow just typed the wrong keywords to get the fitting results, just let me know and post a link :-). --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: RPC Performance/Response Problem
On Thu, Mar 26, 2009 at 9:46 AM, -Lord-67 -lord...@web.de wrote: First of all: Hi to everyone! I'm new to GWT and just programming my first app. Since i've some experience in Java it's not a big problem, but in this case i am stuck and hopefully someone can help me. In my app i make a RPC: On server side i get some data out of a database and save it into an array of type String. Up to 10.000 Strings atm, later on maybe up to 50.000. It is no problem so far. The server is handling this really fast. I measured 5 RPCs with about 500 Strings each and it took less time than 200 milliseconds each (SQL Statement + creating the array). The problem now is: I have to wait 5 SECONDS to get the results of the RPC (the String[] created on the server) on the client side so i can do something with them. Regarding the overall time i measured, these 5 seconds are more than 75% of the time which my app needs. Is it possible that the serialization and deserialization takes that much time? I don't think so and i have no clue where this 5 seconds come from. If someone has any ideas, solutions, suggestions on this problem i would appreciate any help! Seems your bootleneck is in the browser. Javascript is not very fast. Try Chrome and if it is faster you can blame javascript . You can make chunks of 1000 Strings and update the UI in steps. The overwall performance (throughput) will be worse, but the speed perception will be much better (latency), --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: RPC Performance/Response Problem
Have you tried using a List instead of an array? On Mar 26, 2:46 am, -Lord-67 -lord...@web.de wrote: First of all: Hi to everyone! I'm new to GWT and just programming my first app. Since i've some experience in Java it's not a big problem, but in this case i am stuck and hopefully someone can help me. In my app i make a RPC: On server side i get some data out of a database and save it into an array of type String. Up to 10.000 Strings atm, later on maybe up to 50.000. It is no problem so far. The server is handling this really fast. I measured 5 RPCs with about 500 Strings each and it took less time than 200 milliseconds each (SQL Statement + creating the array). The problem now is: I have to wait 5 SECONDS to get the results of the RPC (the String[] created on the server) on the client side so i can do something with them. Regarding the overall time i measured, these 5 seconds are more than 75% of the time which my app needs. Is it possible that the serialization and deserialization takes that much time? I don't think so and i have no clue where this 5 seconds come from. If someone has any ideas, solutions, suggestions on this problem i would appreciate any help! Thanks in advance, -Lord-67 P.s.: Of course i searched for a solution for this problem for hours, if i somehow just typed the wrong keywords to get the fitting results, just let me know and post a link :-). --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
