Our partner Denamik has released a new version of Denamik LoadGen. The execution of massive load and stress tests is now easier than before. You can now record your own user action scripts from within LoadGen, and setup LoadBots to handle the execution of these scripts. LoadGen allows you to manage LoadBots to create remote sessions and evaluate your IT environment under stress. A built-in reporting facility will give you instant results.

What is new in LoadGen 2.3:

• Rewrite of installation and activation of LoadBots
• Rewrite of internal functions of the DUAF language to speed up interaction with XenApp desktops
• Introducing the possibilities to add your own libraries to DUAF scripts

Feel free to check out Denamik LoadGen 2.3, it’s free up to 15 virtual users.

When performing a LoadTest user actions are simulated. This implicates that mouse or keyboard actions are executed based on a script, based on a scenario, and that the script waits for a response on the screen.

The response on the screen can be determined using API’s giving information about windows present, or the controls on the windows. For instance: the script waits until a window is active with the caption “Microsoft Word”.

Another way of determing if a response is given is by comparing the content of the screen with a bitmap. For instance: the script waits until an empty document is displayed in Microsoft Word.

The difference between the two techniques is that a window caption is present right when the application is launched (even if the application is still loading) while the content on the screen is more simular to the way users interact in a session. So looking at a screen region is more accurate, it prevents assumptions (best practice #9 in loadtesting best practices) like “how much time should we wait between lauching an application and clicking on a menu?”.

In this article I will be discussing some best about practices about “true” client side testing (best practice #12 in loadtesting best practices).

Continue reading »

This is the second part in a series two about loadtesting best practices.

The first part focused on the “basics” of loadtesting, most of them where about preparation. You can find the first part here.

In this second part I’ll focus on some more advanced topics which are usefull in a later stage of the process.

Continue reading »

Before I start discussing best practices about loadtesting, let me first tell you what my definition of a loadtest is.

“Testing a system with representative load, to determine if the nominal load can be handled”.

This means that if you start loadtesting you need to know the nominal load and have an expectation of the outcome. You will find that most of the best practices has to do with preparation, not with fancy techniques. An different type of test that is frequently called a loadtest, is a stresstest. A stresstest has a different purpose, as can be read in my definition of a stresstest.

“Testing a system above its nominal load, with the purpose of determining if the system in the future can handle a bigger load and to find a bottleneck.”

LoadTest are commonly used to scale an environment. These environments can be a SBC environment like Citrix XenApp or Microsoft RDS, or a VDI environment. But other environments like file, print or webservers can be loadtested aswell. In fact, if you can create the load by simulating user actions, you probably can perform some sort of loadtest.

Now let’s start with the best practices. I’ve written these down in the past years while I was performing loadtests with the DeNamiK LoadGen, the best practices apply to (almost) all loadtesting applications. You can say I learned it the hard way. Although there’s nothing wrong with that, you can learn from my mistakes.

This is the first part, focussing on the “basics”. Part two will focus on more advanced topics.

Continue reading »

Zo; net thuisgekomen van een avond load testen bij een klant van ons. Wij hebben een implementatie gedaan van SQL 2005 en Reporting Services voor een Management Informatie Systeem. Wij hebben SQL 2005 geïnstalleerd op een virtuele machine binnen VMWare ESX. Doordat SQL 2005 beter kan in zijn jasje zit als 64-bit versie hebben we zowel Windows 2003 als SQL 2005 als 64-bit geïnstalleerd. De machine heeft 2 procs. en 6GB intern geheugen. Vrij ok zou je zeggen….

De laatste paar dagen ben ik bezig geweest met een tool die zeer snel internet acties opneemt. Deze recorder gaat straks deel uitmaken van DUAF. Ik heb dus een flink aantal scripts gemaakt die de gebruikers activiteiten op dit Management Informatie Systeem simuleert. De scripts werkten goed, dus om terug te komen bij de loadtest…. die ging vrij slecht, met 50 gebruikers ging de machine goed onderuit, pagina’s laden via de Reporting Services van SQL duurde zo’n drie tot vier minuten! Dit zijn dus gewoon asp.net webpagina’s.

Na het toevoegen van twee extra procs. en 2GB geheugen ging het een stuk(-je) beter, maar niet denderend veel beter. Ik moet de meetresultaten nog analyseren en dan kom ik hier op terug. Voor nu;

Later….