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.
Thanks!
Best Answer
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.