We have a development server on which we have about 10 identical virtual sites. Whenever we pull up one of the sites, it is very slow (up to 30 seconds for the login page to show up). Once logged in, the application is significantly faster although there is still high latency on each page.

As there could be many causes, I would like some suggestions for how to pinpoint where this latency is happening.

The setup is very traditional. Hardware server (not VM) with a single CPU and 16GB of RAM. It's about two years old and runs Windows 2012, SQL 2012 and IIS 8. Each of the virtual sites is a SQL server based web application in ASP.NET/C# with SSL.

The links below illustrate the latency.

This is upon first pulling up one of the sites:


After logging in, there's still unacceptable latency moving between pages:



If I let the session expire (about 10 minutes) and login again to the same site:


We have implemented Stackify which gives some trace information but I'm not sure how to use to watch, maybe in real time, one specific user pulling up one specific page.

Short of inserting debug-print statements to some logfile, is there anything we can do to see why these long latencies are happening? IIS doesn't seem to update its log immediately so I'm not even sure how to check when IIS is getting the request.

We have of course checked from various different places to eliminate a network issue from one client PC to the server.


  • Very long initial delays with a static part (always over X seconds) are often from network timeouts. Like a reference to a resource on a no-longer existing server / share. – Brian Nov 6 '15 at 22:38
  • I will check that but would that explain the pattern of long initial latency and then shorter subsequent latencies? Why would the subsequent delays be shorter? Thank you. – royappa Nov 7 '15 at 5:48
  • Whenever a network timeout / failure is cached in some way it won't cause the delay again until it stops being cached. – Brian Nov 7 '15 at 14:46

The initial loading part is the loading part of the application. On a dev server you normally do not have keepalive activated (which keeps applications active even when not in use) and starting is slow - among other things because all pages are compiled. As you often restart by loading new pages (it is a development server), this means constant recompiles. Nothing you can do there - except have people work locally on their machine with a copy, and activate keepalive (but that, again, will bring little use on a development machine).

.NET / ASP.NET has not been designed for fast startup times. It does a lot on startup. You could force a manual start before starting to test - which keeps this time out of your measurements.

If things are slow beyond that - start baseline programmer work. I.e. attach a server side profiling tool or integrate Glimpse into your application. This will allow you to target for example slow SQL queries (and these are often a main culprit - people abusing the database). If it is not SQL - a profiler really is needed.

But what you describe primarily sounds like the standard startup time of an asp.net application.

  • I will look into that angle. Some followup questions, if you don't mind: Is this "keepalive" a specific setting or is that something to IIS that gets activated just by users hitting the application? And, how long are these compiled aspx pages kept before they are discarded and the cycle starts again? – royappa Nov 7 '15 at 17:59
  • Depends how old our IIS is. It was added as setting in newest version, I think. It is a download extension in some older version. It does not exist in old versions. compiled stays until the application stops. Which happens standard IIRC 220 minutes without request OR on a visible file change in the application. Which means very often for dev servers. – TomTom Nov 8 '15 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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