How to Run Performance Tests of Desktop Applications Using JMeter

I know what you’re probably thinking. In general, the idea of performance testing of desktop applications is irrelevant, as normally desktop applications are assumed to have only one user. Furthermore, performance testing, in this case, is limited to application profiling, the process of application analysis using 3rd-party profiling tools and white-box source code testing, in order to identify algorithms which are inefficient, overly large and/or non-optimal structures and collections, and to test individual functions, execution time, and associated resource costs, etc.

Use Case

Consider this use case, however. That the desktop application acts as a client for a web service or a database. In such a case, apart from checking the performance of the application itself by analyzing its code and profiling it in the runtime, it makes sense to consider load testing the backend by simulating a situation where hundreds or thousands of desktop applications are simultaneously accessing the backend server. This type of testing provides answers to the following questions: 

• How many concurrent client applications can be served while the response time is reasonably low?
• What are the boundaries of the current  setup, i.e. what is the maximum amount of client applications that can be served?
• How does the application scale (if it does)?
• If the load is overwhelming, does the backend successfully recover when the load gets back to normal?

In general, the approach should be the same as for web or mobile applications load testing:

1. Record the test scenario
2. Perform correlation and parameterization if required
3. Run the test scenario with 1-2 virtual users to ensure that the test does what it is supposed to be doing
4. Add virtual users according to your load test plan
5. Run the test
6. Analyze the results

Just a note on step 1 above, recording the test scenario: JMeter comes with the HTTP(S) Proxy Server, which can capture the requests between the web browser or mobile device and the backend and convert them into HTTP Request samplers. So if the desktop application you need to test uses HTTP or HTTPS protocols for communicating with the backend server, you should be able to record the requests with JMeter and replay them with an increased number of virtual users. Well-behaved desktop applications that require network access support proxy mode either via their own settings dialog or respecting the underlying operating system proxy configuration, which means that you can use JMeter for load testing of almost any desktop application which communicates with the backend over HTTP. 

Configuration

In order to record your desktop application’s network activity with JMeter you need to: 

1. Configure JMeter for recording. The fastest and the easiest way to prepare JMeter’s proxy server is using the JMeter Templates feature. The “recording” template is available via File -> Templates item in the JMeter main menu, and when you click the “Create” button, JMeter will populate a structure suitable for recording. The default port where the JMeter proxy server is listening is 8888 so you need to configure your desktop application to use this port. Regarding the hostname, if the desktop application and JMeter are running at the same machine it might be “localhost” or “127.0.0.1” or the Intranet IP address or hostname.
2. Configure your application to use the JMeter proxy for accessing the intranet or Internet. Depending on the nature of your application, it might be a separate proxy configuration dialog or the respecting underlying operating system’s proxy settings.

For example, this is how the recording of requests being sent by the MSN Weather application with JMeter’s proxy looks like: 

 Once you have captured your desktop application’s network activity, you should be able to replay it according to your load test scenario and see how the backend behaves under the load.

Troubleshooting

Depending on your operating system and the protocol used by the desktop application for communication with the server, you might need to take some extra steps in order to establish connectivity between the application and JMeter. The notes below are applicable for any of Microsoft Windows family:

Some applications cannot route traffic to a local proxy server so you may need to add a loopback adapter.

 If your application uses an HTTPS transport, you may need to add JMeter’s self-signed certificate (the ApacheJMeterTemporaryRootCA.crt file which is being generated in JMeter’s “bin” folder when you start JMeter’s proxy) to the Trusted Root Certification Authorities. To open Windows Certificate Manager choose the certmgr.msc command from Run menu. 

The majority of desktop applications requiring network access either have their own proxy settings or use operating system proxy settings. If this is not the case you can use the netsh command to set a proxy for the Windows Hypertext Transfer Protocol. 

 By the way, you can avoid the majority of the above steps (if not all) if you switch to the BlazeMeter Recorder — your personal cloud proxy. In this case, you won’t have to worry about installing SSL certificates and connecting your application to JMeter. Moreover, the BlazeMeter Recorder can export the tests in Smart JMX mode with automated correlations applied so you won’t have to waste your valuable time detecting and handling dynamic parameters, it will be done already during the recording. 

You can view a lot more about our mobile recorder, as well as our Chrome extension recorder, in addition to nice tips for scripting and analyzing reports, in our on-demand webcast Load Test Like a Pro. 

Finally, be aware that you can test your desktop application even if it does not use the HTTP protocol, you just need to go way down the OSI model to Transport Level, i.e. record your application traffic using a sniffer tool like Wireshark and replay it using the TCP Sampler.