An excellent application of JavaFX and other technologies for load testing.

JavaFX is a platform and language for creating Rich Internet Applications (RIA) that execute on the desktop, in Web browsers, on mobile phones, and on TV. It was introduced in 2007, and version 1.3 was released in April 2010. This article focuses on a real-world application named loadUI that employs JavaFX.

I was minding my own business on July 1, 2010, when the following e-mail arrived in my inbox from the JFXtras developer’s mailing list:

Hi guys, I just wanted to announce a new load-testing tool called "loadUI" which makes heavy use of JavaFX for providing a truly unique approach to load-test creation and execution. [rest of e-mail omitted]. Best regards, Ole Lensmar, eviware.com

Some on the mailing list, including me, were very pleased with what we saw in the demo, making comments such as:

Wow! I'm quite impressed on that gem that you just popped out of the blue! –Tom

I’d like to share information about the loadUI application with you, because it combines JavaFX with other technologies, such as Groovy and OSGi, to deliver an outstanding load-testing tool. A quick way to get an overview of this application is to play the demo videos on the eviware.com site.

Figure 1 is a capture of a portion of a screen in which a Web page is being load tested using the instrumentation provided by loadUI:

Figure 1: loadUI Application in Action

Insights from the CTO on Utilizing JavaFX in this Application

According to their Web site, CEO Niclas Reimertz and CTO Ole Lensmar co-founded [Stockholm-based] eviware in 2005 "out of passion for the community, for testing and for software." I asked Ole to elaborate on their experiences and insight in utilizing JavaFX in this application, to which he expressed the following:

As is hopefully evident, both usability and the actual user-interface are a very high priority for us. For loadUI we have a usability expert helping us design most of the interactions and graphics in the UI, and thanks to the tools available for JavaFX development (Illustrator plug-ins, etc) this process of having a designer creating the originals in one tool, readying them for production in another, and exporting them as FXDs makes for a very flexible workflow in a larger team. Also, the CSS improvements in JavaFX 1.3 help out plenty from a process-perspective, allowing developers to focus on coding while the designers can "post-process" the interface by working with the CSS possibilities to achieve the desired looks.

One major challenge we faced with regard to the transition from creating Swing applications (as in soapUI) to JavaFX is that it is quite a paradigm-shift for Java developers: The JavaFX model is entirely different from Swing and so is the language itself. To avoid writing "Java in JavaFX Script" I really recommend for teams deciding to use JavaFX to invest in an upfront learning period focusing on the language itself and on how things are meant to be done in JavaFX (i.e., patterns, best practices). Otherwise you will most likely come out with a very "disparate" codebase where the same problems related to Swing->JavaFX migration that have been solved differently by different people (which is likely to become a nightmare over time).

Regarding JavaFX performance our top priority has been to create an interface that is as interactive and "smooth" as possible (especially considering that loadUI is all about performance in itself). To keep CPU usage to a minimum we have been quite careful in using many of the "cooler" features in JavaFX and have also done quite a lot of optimizations to keep screen updates to a minimum. For example, all counters are updated twice a second instead of every time the underlying value changes. Obviously the many animation possibilities are something that we want to explore more over time, and a migration to the prism rendering engine is high on our list for improvements (especially as we use a lot of text to display information). Also with regard to performance, quite a lot of time is being put into memory monitoring and management to avoid memory-leaks for very-long-running tests (days to weeks). Here our experience of similar challenges with Swing applications has helped immensely.

Building loadUI and Taking It for a Spin

The loadUI application is an open source project available at sourceforge.net. If you want the latest fixes and features, go straight for the nightly build. You can also download the source code from svn://svn.eviware.com.

Instructions on how to build and run loadUI are at http://github.com/SmartBear/soapui.

Here’s a quick rundown on how to create your first simple Web load test. After the application starts up, it displays the loadUI workspace window, as shown in Figure 2.

Figure 2: The loadUI Workspace Window

Start by creating a new project. Just drag the New Project icon from the component bar on the left to the (now empty) list of projects at the top middle. loadUI will prompt you to create the project (be sure to select the Open Project option) and then open the Project View, where you can start adding components for your first load test, as shown in Figure 3.

Figure 3: The loadUI Project View

For our initial test, we will just use three components:

• The Load Generator to generate a fixed rate of requests
• The Web Page Runner to call our Web page
• The Statistics component to calculate and visualize the response time and related statistics

To illustrate the real-time nature of loadUI, start your load test by clicking the green arrow on the top left of the screen. This will put loadUI into "execution mode" (although there isn’t anything to execute quite yet), and the timer to the right of the button will start incrementing.

Now start building your load test by dragging the Fixed Load Load Generator from the Generators group in the Component Toolbar on the left to the Project Canvas.

Next, drag the Web Page Runner component from the Runners group and enter a valid URL that you can use for load testing into its URL field.

Connect these two by clicking and dragging from the terminal at the bottom of the Load Generator to the terminal at the top of the Runner. You should immediately see the Web Page Runner starting to submit requests. As shown in Figure 4, the configured rate, and results or failures, are counted up on its display:

Figure 4: Configuring and Running a Load Test

Now, top this off by adding a Statistics component from the Analysis group (just drag it on to the Project canvas).

Then, connect the leftmost output of the Web Page Runner to the Statistics component’s input. As shown in Figure 5, you will start to see the statistics being displayed and updated in real time on the component:

Figure 5: Statistics Displayed and Updated in Real Time

That’s it! You’re first (simple) load test is up and running in all its JavaFX glory. You can increase the load by turning the knob on the Load Generator, add more components, and so on. When you’re done, stop the test using the Stop button on the top left. Then, as shown in Figure 6, generate a summary report using the corresponding toolbar button on the top right.

Figure 6: Load Test Summary Report

The report gives an overview of your project, its data and metrics, and so on. You can print the report to a printer or a PDF file.

If you take loadUI for a spin yourself, be sure to give the loadUI team your feedback at the eviware forum.

Technologies Employed by loadUI

The loadUI application uses a multitude of Java technologies to provide its functionality:

• OSGi and Spring DM are used at the core to provide a modular infrastructure that can easily be extended with custom components.
• CometD and HTTP are used for distributing load tests to and collecting test results from loadUI agents. (Read more about this at http://www.loadui.org/Working-with-loadUI/agents-and-testcases.html.)
• Groovy is used for providing a very flexible component infrastructure where components can be added and modified at run time. (Almost all default loadUI components have been created with this.)
• JasperReports is used for creating printable reports from summary data.
• Maven2 is used to automate the entire build process, including installers, OSGi bundles, Groovy component bundles, and so on.
• And, of course, JavaFX is used to provide a truly unique user experience for the load testing domain.

Congratulations, Niclas and Ole

I’d like to thank and congratulate Niclas, Ole, and the rest of the team at eviware for creating an open source facility whose user interface is innovative and top-notch! I look forward to the beta 2 release, due in early August 2010.

See Also

• JavaFX Technology At a Glance
• JavaFX Technical Documentation

About the Author

Jim Weaver is an author, speaker, teacher, and developer in rich internet application technologies such as Java/JavaFX, and may be contacted at jim.weaver@javafxpert.com.