Curious which tools are currently used/popular for load testing a fat client where the protocol isn't readily handled by middlewares of traditional tools like Loadrunner or QALoad..
Here's an example:
I have a fat client talking to an app server. Protocol is TCP/IP, however the conversation between client and server is proprietary and cannot be extrapolated/scripted.
What is the typical tool/approach taken where load is to be generated that emulates (or literally drives) multiple (say 30) concurrent instances (users) of a fat client executing business logic against an app server ?
The fat client is an XP desktop binary.
Thanks in advance for your feedback [img]/images/graemlins/smile.gif[/img]
Try to emulate the users using sockets if the application hardly gets any auto update from the server and the client side processing is less. Also, if the numebr of sockets opened per session is very less.
However, if the client side processing is huge or the automatic server updates to the client is huge, please consider testing through citrix or terminal server.
Generally, FAT client applications are multi-threaded and open several ports on the server. Most of the sockets will handle the automatic update from the server in discrete threads. Hence, I feel they can be tested only through citirx or windows terminal server.
It would be great if we have a load test tool similar to rational robot or QTP that could identify the GUI objects from the protocol payload without storing the objects in memory (like loadrunner Oracle NCA protocol).
Re: Best tools/approach to load test a fat client ?
Both LoadRunner and QALoad support a Winsock interface for recording and script manipulation. You may want to consider this option.
LoadRunner also supports the concept of a binary virtual user, essentially a DLL with the source code from your application representing a particular business process. Because this code would be at the level before you write your information to the socket and after the information is received back from the socket, then you should be able to manipulate your connection variables just as you would inside of your base application source code. I would refer you to your LoadRunner manual set, Virtual User Generator Guide, Advanced Topics, Creating User with Visual Studio.
QALoad may have a similar capability, but I am not as familiar with its manual set to be able to point you to a particular location. Any QALoad Experts out there want to comment on this?
As previously noted, you have Citrix or RDP style virtual users as an option. This brings with it the added challenge of trying to decouple any load generator provided influences from the response time. I would encourage you to add a number of control factors to your test which might include (a) a single user of each business process type running on a Citrix|RDP load generator host which is of the same hardware and software configuration as your core load generator or (b) a single graphical virtual user of each type.
What you will find is that if both your control group and your core load generator group have a response time increase at the same rate then you can be assured that this is due to a common influence which is most likely the application under test, assuming a small tightly controlled test network. On the other hand, if your control group and your core load group decay at different rates then what you are likely looking at is an overloaded generator for your core load.
In general I never run a test with less than three generators, two for core load and one for control load. If I have the luxury of specifying the number and type of generators then I go for four for primary load, one for control load, one hot spare with all hardware and software matched.