GWT – look to the transmitted data

GWT is a great framework. I — a Java developer and I've worked with thin clients using JSP, JSF and GWT. About JSP is to say, the technology is now virtually extinct, but in JSF-e had to spend a couple of years on two projects, and impressions, to put it mildly, not the best: a hodgepodge of JSTL, HTML, JavaScript, and other delivers incredibly “fun”, reaching ecstasy in the moments of analysis of the strange behavior of some complex pages. Yes, the examples all looks neat and simple, but real life isn't like that, and the JSF-project page even medium size and, like, with a competent a leisurely approach when designing, using templates, begins “to smell”, especially in terms of readability. In GWT everything is pretty neat, after writing in the native language of Java, albeit in a shortened version, but the fact that there is more than enough.

If we talk about that in GWT on client load huge JavaScript files-and, here my opinion is. In GWT when you first log on to the client loaded logic, even a lot, but only once. After you download between the client and the server run only clean data business logic. Specifically I have the first download of 3MB, then the AJAX requests/responses, here it depends on what your amounts of data. In JSF-e, at the entrance to any page in your browser and go to the data and a description of the interface in which they appear. In most cases, the size of the interface description (html) is many times larger than the size of the data. To show on the client 1KB of data (a few lines of the table, for example), you will need to send to the browser 15-30 KB is html (believe that images and scripts are cached). But the data on the page are usually much larger than header, menu, blocks, etc. in fact, a rather rich data and functionality page usually weighs between 100-200 KB. GWT to display the same page will be taken from the server 1 KB of data and all. If the users are persistent and long on the website, the loss of the primary kompensiruet 3MB in half an hour. With this in mind, GWT is ideal for implementing jobs, but for normal websites it can be not so good.

In any case, it is only an introduction to a little “dip” in the subject, and the article is not about comparing technology and about how spying for data running between your browser and the server can help in solving problems and optimizing client-server interaction. At the time of writing, we have used a very much older GWT 1.5 and to transmit DTO as old and no longer supported library Gilead. I have plans to upgrade to the latest version of GWT and the rejection of Gilead in favor of GWT-shnogo RequestFactory. Regardless of the technology, tools and debugging techniques remain the same. I used FireFox with FireBug installed.

How we found memory leaks

Once we decided to upgrade the technology used – GWT, Gilead, JBoss, Hibernate. Replaced the library, launched the server, recompile the project. Launched, tested, and decided to go into commercial operation. Updated the server, waiting. First reviews – works faster. After an hour things started to “hang out” in 15 minutes “stood stake”, still later the server went down in OutOfMemory. Frantically began to try to understand the problem, restarted the server every hour at this time. Again, the article is not really about this, the upshot was that the leak to detect and failed, and we fell back to the old version. I have long tried to analyze the dumps, to do load testing, but never found the source of the problem.

A month later, the tester was complaining about the fact that one of the logs in the System with it (he in turn complained about it users). I have this problem not reproduced, I asked him to install FireFox and FireBug and see what is happening there. It turned out that when you open the log on the client boot package with a size of about 4 megabytes (!!!), in order to display a plaque of the ten records. The source of the problem was immediately found on the server when retrieving data to display, there was no limit to the number of records read from the database, and the client has loaded all the contents of the database table. I have test database developer in the table was about fifty records, and the tester was a fresh dump of the industrial base with thousands of entries in this table. Fixing the problem – adding a single line of code.
I think the reason for the “fall” of servers when updating the technologies in this journal. Why old technology cope? Apparently, they are less used caching data (indirectly confirmed by reviews that the new technology worked faster). Unfortunately, feil has hit so hard on our users (and of course for us developers and vnutrennem) to update JBoss was made only a year, regarding GWT and Gilead official plans at all. So that's a forgotten line of code can demolish a big plan to steal hundreds of hours of work, and add gray hairs to many people.

How to save network traffic and memory

Do not be lazy, and spend a couple of hours to see in FireBug what is sent to the server and back, it is possible to discover some interesting things. A concrete example: a client (browser) periodically requests from the server notifications. In fact, it is necessary to transfer data to the server about who has requested, in response to list. We have client stores the User object that contains a lot of information about it, including a variety of payroll data. Now, a method of requesting data from the server was implemented just – passes the User object as a whole. Similarly implemented, and many other methods. Looking under the debug, I saw that the size of the serialized into a string and transmitted to the server User-and 15кБ. But on the server in the cache session user has a copy of this object and to retrieve the requested data, the method is General enough for a user ID. If you replace the method in the User object for its ID, the request size can be reduced 15кБ to 50-100 bytes, and then call a method without parameters, and the data the user to take from the current session.

It seemed that for modern network infrastructure 15кБ? Dust! But we should not forget that many queries, and the user in the system is not one. Besides, along with network resources on the server consumes resources of CPU and memory to convert the received 15кБ into Java User object which will proudly pulled out the ID for the query, and all the rest will be left to the garbage collector.

As I was doing load testing

When we began to fall the server when upgrading technology, one of the attempts to detect the source of the problem was the load testing process. Quick browsing and searching of free utilities and software libraries have not helped in creating the test environment, so I decided to try to write something simple yourself. Everything points to the GWT server is HTTP requests, so you can try to emulate their standard tools of the Java language. Only here what to pass in queries? Again, came to the aid of FireBug. Go to the client, perform any activity in FireBug-e pick up the contents of POST requests. Samopisnaya load testing tool is pretty short and quite functional. A User performs a repetitive set of actions, i.e. sending HTTP requests. In different threads run a few dozen/hundred of these objects and give a decent load on the server. Right now testing is under load the System to test after switching to JBoss 7: CPU resources used by the server, 90%, overnight eaten 500MB of memory when logging into the client part of a tangible "confusion", and it means that the load is good!

Conclusion

All of the above applies not only to the GWT, but any thin client: look under debug that runs between the server and the client. It not only can give directions for narrow/problematic areas, but also to help in better understanding of the technology used.

Article based on information from habrahabr.ru