This blog is based on the experience of Jan Swaelens, Software Architect at Sofico. He is responsible for automatic performance testing of the company’s new web platform based on GWT and SmartGWT. Sofico is specialized in software solutions for automotive finance, leasing, fleet and mobility management companies.
Choosing GWT and SmartGWT over other technologies
About 2 years ago Sofico started a project to replace its rich desktop application (built with PowerBuilder) with a browser based rich internet application. The developers selected GWT and SmartGWT as core technologies to leverage their in-house Java expertise because they believed in the potential of what these (fairly) new technologies had to offer. Their goal was to replace the existing desktop client with a new one which ran in a browser. Their eyes where set on a better user experience and high degree of customization possibilities to give their customers the flexibility and adaptability that they need to run their businesses.
Need End-to-End Visibility into GWT Black Box
GWT was a great choice as they could soon deliver the first basic version. The problems started when trying to figure out what was actually going on in these frameworks in order to analyze performance problems reported by the first testers.
Requirement #1: Browser to Database Visibility to “understand” what’s going on
Do you know what really happens when a page of a GWT application is loaded? No?! Neither did the developers from Sofico. Getting insight into the “Black Box” was therefore the first requirement because they wanted to understand: what really happens in the browser, how many resources are downloaded from the web server, which transactions make it to the app server, what requests are cached, where is it cached and how the business logic and data access layer implementation impacts end user experience.
The following screenshots show the current implementation using dynaTrace (sign up for the free trial), which gives the developers full visibility from the browser to the web, app and database server. The Transaction Flow visualizes how individual requests or page loads and services by the different application tiers are processed.
Requirement #3: Correlated Server-Side Performance Data
Tying browser and server side together gives the developers the full performance picture which they wanted. The following shows a PurePath for a network request executed by the browser going all the way to the database. Having that level of visibility allows them to tweak and optimize their implementation:
Requirement #4: Automation, Automation, Automation
Next Step: Real User Monitoring
Read more and test it yourself
If you want to analyze your web site – whether it is implemented in GWT or any other Java, .NET or PHP Framework sign up for the dynaTrace Free Trial (click on try dynaTrace for free) and get 15 days full featured access to the product.
Also – here are some additional blogs you might be interested in
- Top Performance Landmines in Modern Web Applications
- Web Performance Analysis with Selenium
- Performance Impact of Exceptions
If you happen to be a Compuware APM/dynaTrace customer also check out the Test Automation features of dynaTrace on our APM Community Portal: Test Automation Video