WinBlogs….

Couple days ago, I had to setup a machine for a customer of ours who will host a web site for some Microsoft conference in Croatia. Since, this is the biggest IT conference in Croatia, I really tried to take everything to the next level and tweak the hell out of that machine

For stress testing, I used Siege with  url.txt file where I saved about 20 links from the web site I was testing, in order to emulate the real world scenario as much as possible.

So, for starters, lets throw out some numbers, to see how the machines copes when the IIS install is out of the box :


The test has been run with 150 concurrent users.
Lifting the server siege...      done.                                         Transactions:                    5215 hits
Availability:                 100.00 %
Elapsed time:                  59.83 secs
Data transferred:             472.64 MB
Response time:                  1.69 secs
Transaction rate:              87.16 trans/sec
Throughput:                     7.90 MB/sec
Concurrency:                  147.32
Successful transactions:        5215
Failed transactions:               0
Longest transaction:            5.99
Shortest transaction:           0.25


So, lets take look on the Longest and Shortest transaction value – pretty jumpy, right?

It took the machine to serve the page, in a range of 0.25 to almost 6 seconds? SLOW!

STOP!  Tweaking time

One note – do not run 32 bit apps in 64 application pool – waste of resources!

Since this is a website which has around 120 requests to the IIS server for loading one page  I have TURNED OFF the compression!

Why? Simple tradeoff, more bandwidht for less CPU usage. With compression turned on, site had around 1.2 MB ( a lot, I know ), but with compression turned off, site loading time went down for almost 50%, and the site size went for for only 100 KB   -  a good trade off in my opinion!

Next -  lets cache this sucker out, I turned on caching for both dynamic and static content, pretty simple setting for a huge improvement!

Now, lets dive into some more complex tweaking -  .Net and registry tweak.

Does the “word”  MaxConcurrentThreadsPerCPU sound familiar?

Basically, with standard out-of-the-box setting, number of requests per CPU is limited to 12.

By default, this entry doesnt exist in the registry, so we need to add it.

MaxConcurrentRequestsPerCPU within HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0 determines the number of concurrent requests per CPU.

Since that value in .NET 4 is already set to 5000, there’s no need to change that is you run a .NET 4 application, but in my case, I had applications with .NET 2, .NET 3.5 and .NET 4 running on the machine, so I have set the value  MaxConcurrentRequestsPerCPU to 0 – which means unlimited.

Lets do some load stress with the new IIS and .NET setting. Again, we will run Siege with 150 concurrent users.
Lifting the server siege...      done.                                         Transactions:                    8171 hits
Availability:                 100.00 %
Elapsed time:                  59.58 secs
Data transferred:             643,80 MB
Response time:                  0.96 secs
Transaction rate:             137.14 trans/sec
Throughput:                     10.73 MB/sec
Concurrency:                  131.67
Successful transactions:        8171
Failed transactions:               0
Longest transaction:            1.99
Shortest transaction:           0.15


So, as we can see, we had almost 3000 more transactions, better transaction rate and load time improved over 3 times ( 0.15 to 1.99 sec ).

But wait, there’s more, in the next post, we will do some network level tweaking, and see if we can get even more juice from the machine.

NOTE:  Since I didnt write the applications  and didnt have access to them to review them, I had to optimize the server as much as possible.