21 September 2010

Testing TMG NLB in a lab with a great little web load generator

I am currently busy testing TMG as a Network Load Balance device for various web servers and applications.  One of the biggest problems is to generate test traffic.

Yes TMG can generate test traffic but it is not a load simulator.  So you either need a few of your friend to generate some traffic  for you (and this is harder than it sounds) or you need a tool.  There are of course many different tools out there but I was looking for something simple quick and easy and free. 

I stumbled onto an old little load tester called Diesel Test.  http://sourceforge.net/projects/dieseltest/files/  It allows you to record your actions and then use them to generate multiple request from multiple users.  Importantly from a TMG NLB perspective is they way it handles cache and cookies - it discards them after every connection.



So now we have a traffic source that is reliable and configurable.  Next I need to set up a test bed of web servers.  I am just using two but you can easily use more.  Since I am really in an artificial environment I need to change some of the normal environmental IIS behavior.  Be default http keep-alive is enabled.  This will keep a connection open should additional web requests come through from the same host.  Great in practice - bad for my test. 

From the web server's IIS console
  • Select the site to be used for testing
  • Open HTTP Response Headers
  • Click Set Common Headers from the Actions menu
  • Un-check Enable HTTP Keep-alive
  • Check Expire Web Content: Immediately


The next thing I need is to be able to track the usage or load on the two different web servers.   This is important since I will be load shedding from the one to the other.  For this I am going to use performance monitor. I set up one of the server with the following counters:

Web Service
  • Anonymous Users/Sec
  • Total Anonymous Users

I configure my TMG server to Publish a Farm.  and I include the two test servers.  I use Cookie based affinity.  I prefer this method since many of the connection will be coming from the Internet from behind a reverse proxy.  This means all those sessions would be from the same IP.

So all the pieces are ready for testing now. I will be doing the following load balance tests.

Drain one server
Resume one server
Drain both servers
Resume both

First up I turn on the traffic. Then I check to see that my traffic is being load balanced across my servers.
As the traffic is ramped up from Diesel Test I can see that the load is increasing and that it is being balanced beautifully across the two servers.



Next I am going to drain one of the servers.  This is done by Clicking on the Farm in the TMG toolbox, selecting the servers tab and clicking on Drain.  Then OK and APPLY.


The result is that as the configuration is applied to TMG the traffic is then shifted.  The blue line is session dropping off the one server.  As the blue line drop the red one increases by the dropped amount.   


Now what would happen if i want to stop both servers an turn off the application gracefully.  Sure I could change the rule from allow to deny, but that will just drop all traffic once the configuration is active.  This would drop active sessions.  So I will drain the second server now.   We now expect to see all the sessions dying off.


Servers will remain in the drained state unless you resume them.  This means you can reboot etc.
Next I resume my "Blue server" and we can see the load comes back.


Now to resume load balancing. I resume the "Red Server"  and watch the graphs with great anticipation.



We can once again see, by looking at the graph, that the load is being shared by both servers.  This should be enough to be able to proceed to the next step of testing this NLB configuration with an actual web application with actual users.

This test would not have been possible without a stable source of reliable traffic.  It is great to find a little app like this that takes seconds to setup and configure and lets you worry about what you really want to test.

No comments:

Post a Comment