2012-12-10

We recently had a new production server built to serve an ASP.NET 4.0 business app. Specs for the new server are Windows Server 2008 R2, 2-core Xenon, IIS 7.5, 2Gb RAM (soon to be 4Gb). Previous to the new server, we had been running/testing the app on a Windows Server 2003, single core, IIS 6, 4Gb RAM.

Our app uses an ASMX web service to validate logins against Active Directory using LDAP.

We noticed immediately that there was a significant increase in response times when hitting the web service from the new server, but only on 'first-hit'. Oddly enough, 99.9% of the time the response time for this 'first-hit' is 15 seconds (literally between 15000 and 15999ms). Subsequent hits result in typical response times (

a) wait 2-3 minutes, or

b) recycle the app pool, or

c) restart IIS

The app is running under its own app pool, using .NET 4.0 Framework.

Here's the current state of the app and IIS:

All Recycling turned off for all pools (Idle Timeout & Fixed Intervals)

No debugging references in Web.config

App is pre-compiled (published via Visual Studio)

Managed Pipeline = Integrated

Identity = NetworkService

Running in 64-bit mode (changing to 32-bit mode had no effect)

I first thought this was a recycling issue as I've seen many posts relating to this. However, it doesn't explain why the 'first-hit' behaviour occurs after waiting for only 2-3 minutes.

The only thing I haven't tried is the IIS Warm-Up. This is because a) I don't have rights to install it and b) in my mind, the 'first-hit' is to the actual login page, not the service (unless I'm mistaken). The login page loads in under 300 ms, regardless whether it's 'first-hit' or not.

One other note... We actually have two new prod servers, which are identical. One of our other apps uses load-balancing across both of the servers. The app in question here is only located on one of the servers and is not being load-balanced. Could this have something to do with it..?

Hope you can help!

Show more