I have been working with a customer who wants to look at the performance on Rational Team Concert across a WAN spans most of the globe. The basic approach is pretty simple – we want to see what the end-user experience is (across this WAN) as we increase the load on the central server. The nice thing about RTC is you can run everything on a central server – and just hook clients (browsers/IDE’s) to the server.
Go generate a load – we create a series of calls to the server in a pattern that matches the typical usage pattern of this customer. Ideally, we would capture traffic using a performance test tool, and play it back, but unfortunately their performance testing tool (HP’s LoadRunner) is struggling to capture this HTTPS traffic. We may end up using Rational Performance Tester (which we know works because that is what the RTC test team uses) – but this might not be an option here. Instead – we will be using the commandline tool to generate traffic, and then run this from different machines to simulate a load. Next step is to get the pattern of traffic right – and there I am using an excellent article on jazz.net (https://jazz.net/library/article/814). Next we will look at running a functional testing tool on some Eclipse clients in different location on their WAN – and note the changes in response time as we change the server load.
Other ways to generate the load include using cURL to send REST messages directly to the server, or writing Java code against the API for RTC. If the commandline turns out to be insufficient to generate the right load patterns, we may just use one of these options.
We did something similar with RTC 2 a few years ago – and I watched the server soak up loads of 1000+ (simulated) users without much problem – and client performance was still good. We had some of our testing techies work on the test generation, and one of my other colleagues did a lot of Java coding. Actually, we rather overdid the load generation and people who looked at our usage pattern afterwards suspected we had generated hyperactive users that did the work of two people in terms of the number operations per hour.
The nice thing about this is we get to work on a real WAN with proper hardware and watch RTC perform really well.