Simulating Exchange 2003 load with LoadGen

Next I wanted to simulate some load on the Exchange 2003 deployment.  To do this I wanted to use the Microsoft LoadGen application, and install it on a temporary, dedicated Virtual Machine.  I therefore deployed a new VM, and so that I wouldn't need to worry too much with the performance of the LoadGen machine itself, deployed it with twice the memory and CPU count as the Exchange 2003 back end.  As it's only temporary VM, I don't need to worry about this high allocation eating into available resources too much.

Once the server was built I RDP'd to it and downloaded the 32-bit version of LoadGen available here.
You also need to install the 32-bit Exchange 2007 management tools available here.

The management tools install insists on doing the 2007 schema updates, despite the fact it's just the tools I'll be installing.  I'll be installing Exchange 2007 in the not too distant future, so it's not a huge issue.

The installation of the Exchange tools completed successfully.

With the Exchange Tools installed I could begin the installation of LoadGen.

The installer is pretty straight forward, accept the licence agreement, choose the install location and it completes.

I could then launch LoadGen and opt to start a new test.

I'll be creating a new configuration.

I kept the test duration with the default times of a 10 hour run and an 8 hour day, and entered the Directory and Mailbox passwords.

To keep the numbers nice and simple, seeing as I have 1GB mailbox limits, and a 50GB database drive, and 3 databases I opted for 30 users total, with 10 per database, which would take (if fully utilised) the 50GB drive up to 30GB used, leaving 20GB for logs and public folders.  As long as I don't generate more than 25GB of logs total before I perform the first backup and log truncation this should be fine.

Next, I added some distribution lists and contacts for the simulation, but avoided any settings that may actually generate external email.

LoadGen then creates the test AD objects.  I then loaded up dsa.msc, and created 4 OU's in the LoadGen users OU, one for each type of Outlook 2003/2007 cached/non-cached combination, and moved the LoadGen created users via simple round robin into these four OU's.  This way I get a split between user profiles on the same database.

Then, back in LoadGen, I created 4 user groups, pointing at each of these OU's, and configured all of them as very heavy profile.

I'm only generating load from this system, so don't need to configure remote load generators.

Finally, you get a summary of selected options.

I saved the config so I could easily re-use it later, and started the initialisation phase.  A few hours later the initialisation phase completes, and I am left with a 20GB utilisation of the 50GB data drive (10 of the 20GB being logs).

I also ended up with a nice spread of users across the three mailbox databases, in the 250-320MB region but all with an item count of exactly 7809.

Now, back in LoadGen, I could start the simulation.

Before the 8 hours of the simulated day starts, I took the opportunity to log onto the Exchange Back-End, and start up perfmon adding some basic counters.

RPC Averaged Latency is really the one I'm interested in, it's a very good indicator of how clients will perceive performance.  Anything consistently under 20ms and client performance will be excellent, and the slower database disk won't actually be a cause of significant problems.  Under 50ms and it might be a little laggy but basically usable.  I added the disk counters so that if RPC Averaged Latency is high, I can either put it down to the disk design, or if it doesn't show high disk queues and utilisation at the same time as high RPC Averaged Latency, it would point me to look somewhere else for a bottleneck.

With the simulated day well underway, I took another look at the perfmon.

I wasn't even seeing Averaged RPC Latency spike above 10ms.  That's pretty excellent, and eradicated the minor concerns I had over disk performance due to the results I saw from JetStress earlier.

Many hours later, the tests completed and a summary was presented.

I was fairly pleased with the results, latencies all pointed towards this configuration being pretty solid for the kinds of load I'll be throwing at it.  The real question now is will it be able to keep those latencies under 20ms when I add a 2007 back end with another 50GB partition on the same disk.  That's still some way off yet though but the results should be interesting.