Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 (<100ms - 300ms) for all users. However, waiting any longer than 2-3 minutes will cause this 'first-hit' behaviour to happen again.

Response times to the same service, on the old server, are never over 300ms... Even after restarting IIS6.

The Trace Route for both the old and new servers is the exact same. Same with the Ping response times.

After much testing, the only reliable way to reproduce (and thus define 'first-hit') is:

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!

share|improve this question

1 Answer 1

up vote 0 down vote accepted

So our IT guys ended up fixing the problem.

While they weren't exactly sure what the actual problem was, they think it was because our domain name had two IP addresses associated with it (for load-balancing). Since configuring and starting Round Robin (VMWare), the issue seems to have resolved itself.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.