A question arose in the forums the other day from someone looking at running some scripts for load testing and wanting advice on how best to run multiple instances of the same script. See the thread here for some useful ideas and links. I thought I’d summarise them here.
An article on using Macro Scheduler for load testing can be found here.
If you are new to load testing you might not be aware of the options available to you for multiplexing desktops. Obviously you can’t run a script that interacts with the desktop – focuses windows, sends keystrokes and mouse clicks etc – more than once at the same time on the same desktop. Chaos would ensue. If you want to simulate a bunch of users interracting with an interface you’re going to want lots of desktops running at the same time. You could, of course, use lots of real PCs. But that’s a rather expensive approach, especially if you want to run 100 or 200 users at the same time.
Here are some commonly used options:
Windows Terminal Server – Remote Desktop
Windows Server 2003/2008 allows multiple desktops to be active at a time. The standard version comes with a license for up to 5 simultaneous client connections (CAL – Client Access License) and you can buy further CAL packs to increase the number of simultaneous desktops you can have at any one time.
You can then run multiple desktops – either for the same login, or different users, and have scripts running in each one. So with one physical machine you can run multiple desktops to simulate multiple users. Clearly the more desktops you run the more the effect on performance, and since you may be trying to test the effect on performance there’s a balance. Many companies will run, say 10 physical machines, running, say 20 desktops each, to give you 200 virtual users.
One thing to consider with this approach is that since each desktop is running on the same machine you should be careful that your scripts don’t try to write to the same resources and cause conflicts – e.g. if they all try to write to the same file at the same time.
Virtualization
Virtual PC is a free product from Microsoft that lets you create virtual machines. You can create a machine, install, say, Windows XP, into it and run that machine in it’s own window on your desktop. You could therefore create multiple virtual machines and run them simultaneously. Each have their own desktop and therefore UI automation routines can run in all of them simultaneously. Unlike with Remote Desktop each desktop is completely separate from the other so you would have no issues with accessing local resources. You would have to consider the Windows licensing implications and how the cost compares to Windows Server client access licenses.
Creating multiple virtual machines can also take some time, whereas with the remote desktop approach the operating system only needs to be installed once. There is a way to clone virtual machines by copying the VHD files and then running NewSID in the machine to give the OS a new security ID.
VMWare Server is another virtualization platform. There’s also Parallels. Again, when cloning virtual machines you’d have to make sure they have different SIDs. VMWare offers a solution called Lab Manager which I believe is intended to make the process of provisioning multiple machines easier, though I’m not experienced with VMWare.
In each case you would want to ensure that the approach you use isn’t adding to the performance bottleneck or it might make the tests pointless. Verify how many virtual machines or desktops your server can cope with and find the right balance.
You may need to run multiple copies of the same (or different) scripts at the same time for other reasons and these tips will be valid in this case too. For example we’ve worked on automation scenarios where lots of data needs to be entered into a legacy user interface. The data may arrive at different times. Rather than work through the queue one at a time, multiple desktops are fired up for each item so that there are lots of tasks taking place at the same time, therefore speeding up the entire process.
