Andreas Grabner About the Author

Andreas Grabner has been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi

How to Performance Test Automation for GWT and SmartGWT

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.

Developers started off by using the “usual suspects” – browser-specific Dev Tools for Chrome, Firefox and IE. Back then, the built-in tools lacked first class JavaScript performance analysis capabilities which made it difficult to analyze a complex browser application. Additionally, there were no integration capabilities into server-side performance analysis tools such as JProfiler which would allow them to analyze the impact and correlation between server-side and client-side GWT code. Taking performance seriously, the performance automation team came up with some key requirements for additional tooling and process support.

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.

End-to-End Visibility gave the developers more insight into how their GWT Application really works and what happens when pages are loaded or users interact with certain features.

End-to-End Visibility gave the developers more insight into how their GWT Application really works and what happens when pages are loaded or users interact with certain features.

A great view for frontend developers is the timeline view that shows what happens in a browser when a page gets loaded, when a user clicks a button that executes AJAX Requests, or when backend JavaScript continuously updates the page. It gives insight into performance problems of JavaScript code, inefficient use of resources (JS, CSS, Images, …) and highlights whether certain requests just take a very long time on the server-side implementation:

Developers love the timeline view as it is easy to see what work is done by the browser, where performance hotspots are and even provides screenshots at certain events

Developers love the timeline view as it is easy to see what work is done by the browser, where performance hotspots are and even provides screenshots at certain events

Requirement #2: JavaScript Performance Data to Optimize Framework Usage

GWT makes it easy for Java developers to develop web applications. The more work a framework “hides” from the developer the harder it is to find potential problems. Even though developers implement code in what they think is the most efficient way, it may not be when using specific framework features. Sofico, therefore, required full performance visibility of all code executed by the app – that includes code written by the developers, code generated by the framework as well as the core framework code. The following screenshots show the performance visibility the team has now. The Browser Hotspot view gives the developers insight into which JavaScript methods are executed too often or are taking too long:

The Browser Hotspot View tells developers which methods are called very often and which ones are performance hotspots giving them a starting point for optimization.

The Browser Hotspot View tells developers which methods are called very often and which ones are performance hotspots giving them a starting point for optimization.

Identifying problematic methods that are either called too often or take long to execute is just the first step. Drilling into the so called Browser PurePath shows them where these methods are called from (from a script block or JavaScript handler). Seeing the actual call trace including method arguments, exact method timings as well as the actual JavaScript source code allows them to optimize their own JavaScript code or the way they use the framework.

JavaScript method level visibility including the full PurePath and actual JavaScript code makes it easy to understand performance hotspots.

JavaScript method level visibility including the full PurePath and actual JavaScript code makes it easy to understand performance hotspots.

Requirement #3: Correlated Server-Side Performance Data

A lot of code in GWT Applications still executes on the AppServer. As with most modern application frameworks, most of the work is actually done in the framework’s core libraries which hide a lot of the complexity. This is a great thing as developers can focus on their own code. Sofico, however, wanted full server-side performance visibility correlated to the end users actions in the browser to better understand how to optimize the server-side GWT code. The following screenshots show the same hotspot feature as Sofico uses for JavaScript. It shows the methods that spent most of the time on the CPU, I/O, Wait or Synchronization.

Getting full visibility into server-side performance often reveals framework internal problems such as excessive Exception handling.

Getting full visibility into server-side performance often reveals framework internal problems such as excessive Exception handling.

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:

Seeing the full end-to-end PurePath (from Browser Request to Database) allows Sofico to fully understand where they can optimize their implementation and configuration of GWT

Seeing the full end-to-end PurePath (from Browser Request to Database) allows Sofico to fully understand where they can optimize their implementation and configuration of GWT

Requirement #4: Automation, Automation, Automation

Giving developers the tools they need to analyze their code from browser to database is great – but – it’s better  if this can all be automated. Sofico invested a lot in browser test automation using Selenium. The next step therefore, is to automatically analyze certain performance characteristics when running their browser tests. They are now analyzing metrics such as Page Load Time, Time spent in JavaScript and Number of Database Statements for each of their features with an automated Selenium Test. Whenever they have a regression, like a JavaScript takes twice as long as in the previous build – they are automatically notified about this regression through their Automated Performance Regression Analysis Platform:

Besides functional verification of Selenium they also get automatic performance and architectural verification by looking at metrics such as page load time, # of SQLs, …

Besides functional verification of Selenium they also get automatic performance and architectural verification by looking at metrics such as page load time, # of SQLs, …

Next Step: Real User Monitoring

Giving developers the tools they need to build optimized and fast websites is great. Having a test framework that automatically verifies that performance metrics are always met is even better. Ultimately you also want to monitor performance of your real end users. The next “evolutionary” step therefore is to monitor performance for every end user, from all different geographical regions and all browsers they use. The following shows a dashboard that provides a high level analytics view of actual users. In case there are problems from specific regions, browser types, or specific web site features, you can drill down to the JavaScript error, long running method, problematic SQL Statement or thrown Exception.

After test automation comes production: You want to make sure to also monitor your real users and catch problems not found in testing

After test automation comes production: You want to make sure to also monitor your real users and catch problems not found in testing

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

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

 

Comments

*


− 7 = two