I have deployed an application written in ASP.NET 2.0 into production and it's experiencing some latency issues. Pages are taking about 4-5 seconds to load. GridView refreshing are taking around the same time to load.
The app runs fine on the develpment box. I did the following investigation on the server
Checked the available memory ... 80% used.
Cheched the processor ... 1%
Checked disk IO from perfmon, less than 15%
The server config is
Windows Server 2003 Sp2
Dual 2.0 GZH
2GB RAM
Running SQL Server 2005 and IIS only
Is there anything else I can troubleshoot? I also checked the event log for errors, it's clean.
EDITED ~ The only difference I just picked up is on the DEV box I am using IE7 and the clients are using IE6 - Could this be an issue?
UPDATE ~ I updated all clients to IE8 and noticed a 30% increase in the performance. I finally found out I left my debug=true in the web.config file. Setting that to flase got the app back to the stable performance... I still can't believe I did that.
First thing I would do is enable tracing. (see: https://web.archive.org/web/20210324184141/http://www.4guysfromrolla.com/webtech/081501-1.shtml)
then add tracing points to your page generation code to give you an idea of how long each part of the page build takes:
System.Diagnostics.Trace.Write(
"Starting Page init",
"TraceCheck");
//Init page
System.Diagnostics.Trace.Write(
"End Page init",
"TraceCheck");
System.Diagnostics.Trace.Write(
"Starting Data Fetch",
"TraceCheck");
//Get Data
System.Diagnostics.Trace.Write(
"End Data Fetch",
"TraceCheck");
etc
this way you can see exactly how long each stage is taking and then target that area.
Double check that you application is not running in debug mode. In your web.config file check that the debug attribute under system.web\compilation is set to false.
Besides making the application run slower and using more system memory you will also experience slow page loading since noting is cached when in debug mode.
Also check your page size. A developer friend of mine once loaded an entire table into viewstate. A 12 megabyte page will slip by when developing on your local machine, but becomes immediately noticeable in production.
Are you running against the same SQL Server as in your tests or a different one?
In order to find out where the time's coming from you could add some trace statements to your page load, and then load the page with tracing turned on. That might help point to the problem.
Also, what are the specs of your development box? The same?
Depending on the version of visual studio you have, Team Developer has a Performance Wizard you might want to investigate.
Also, if you use IE 8, it has a Profiler which will let you see how long the site takes to load in the browser itself. One of the first things to determine is whether the time is client side or server side.
If client side, start looking at what javascript you have and optimize / get rid of it.
If server side, you need to look at all of the performance counters (perfmon). For example, we had an app that crawled on the production servers due to a tremendous amount of JIT going on.
You also need to look at the communication between the web and database server. How long are queries taking? Are the boxes thrashing the disk drives? etc.
Related
I am working on a .NET WebForms application and I have observed that whenever I build, after the build, the very first page load takes longer to load than usually. This happens even if I wait after building before I load a page. Is there a way to increase human workforce performance by changing IIS/.NET to initialize things on postbuild instead of first page load?
Yes you can, like this.
Quoting:
You can use Application Initialization Module which comes in-box with IIS 8.0, like this:
<applicationInitialization
doAppInitAfterRestart="true" >
<add initializationPage="/" />
</applicationInitialization>
This will send a request to the root of your app (initializationPage="/") every time your app starts automatically.
You can also configure the Start Mode for your application pool to Always Running which means every time IIS restarts, it will make sure to start your application pool immediately (this if from right click on your application pool then Advanced Settings).
Professional servers have hardly any latency, though it requires quite a bit of tweaking. Also, by default, applications recycle regularly on IIS (as well as when some kinds of exceptions occur, when some files are changed, or when some thresholds are reached). Professional web application hosting is anything but simple :) You might get help with that on Server Fault, perhaps.
Another option is to avoid mixing pre-compilation and JIT-compilation - if you only pre-compile, you don't need to do any compilation when the application is deployed, resulting in faster startup times. If you only deploy sources, the application domain doesn't need to be torn down when you make a change, which means that only the change needs to be recompiled, which is much faster.
And of course, ASP.NET Core is much, much faster in both scenarios - it can do the whole compilation in-memory, unlike the legacy system which uses csc to build multiple assemblies, save them to disk, load them from disk, merge them together, save that again, just to load it again and initialize.
I'm just diving into Web API development (ASP.NET 4.6, Visual Studio 2015) and I have a strange problem. When running my web application with the startup option "Don't open a page. Wait for a request from an external application" selected, the initial request that is supposed to kick things off is very delayed.
For example, I start debugging and the VS output window is blank. I figure this is normal. Then in Fiddler I send the initial request. The time it takes for VS to start spitting out debug information and actually spinning up the application varies: sometimes it is instantly, most of the time it is about 10 seconds. Occasionally it will take up to 1 minute. During that time nothing is happening.
Edit:
Clarification: this is a delay before ANYTHING happens (i.e. before bootstrapping/spin-up occurs)
This mysterious delay also occurs when the project is configured to start with the default MVC home page. And it also happens when running without debugging. This happens with fresh project made from the template. Same goes for ASP.NET 5 template app. Also happens when I run in full IIS.
I wonder if it's a problem specific to my computer, as I tried all these things on another machine and there were never any delays.
I found out what was stalling out the HTTP request: my antivirus. I have AVG Internet Security Business Edition on my system. All that was required was to select "Temporarily Disable AVG Protection". Boom--right away, all my HTTP requests came through instantly.
Additional info: I tried disabling individual components from the AVG control panel, but none of those provided the fix. It seems, unfortunately, that it's all-or-nothing with AVG.
Conclusion:
At least on my system, completely disabling AVG (or presumably, uninstalling) AVG is required for ASP.NET development where waiting up to 1 minute for the first request to be processed is unacceptable.
I'm working on a fairly large ASP.NET web application and I'm taking a big productivity hit when I do work in the interface. I can zip through adding features to the database and API, then I hit the interface and having to recompile and run eats up a lot of my day.
For example if i'm working on a tricky bit that isn't behaving quite right and requires a number of tweaks I'll have to go through multiple [stop/tweak/build/run/log in/navigate back to page] cycles, which really kills my flow and has me staring at the screen with my finger hovering over the hackernews bookmark each time.
I've been fiddling with ways to get around this problem but I haven't improved my situation much. Here's what I've found so far:
visual studio will restart the app frequently when you change static files (js/css/etc), which shouldn't require a restart. If you run VS with IIS express instead this problem goes away.
If I know I have a bunch of messing around to do i'll cut/paste my code into a server script tag on the markup page, run the product, and tweak until it's good, then cut/paste it back. This is annoying because it often requires setting up a number of Imports page declarations and code editing features in ASP.NET files, while better than ever in VS2010, is not as good as in C# files. Plus, it still restarts the app occasionally once enough changes are made.
I can exclude the codebehind file from the web application project, change the "codebehind" attribute in the aspx page declaration to an "src" attribute, then edit the code from there while the app runs (until i make enough changes to trigger a restart.) However now intellisense doesn't work in the codebehind, among other things.
Am I missing something blindingly obvious here, or is development in ASP.NET web applications really supposed to be this slow? Thanks for any solutions you can offer.
I never run my applications through Visual Studio. Set yourself up with IIS and then configure a site to point to the location of your application along with a faux domain. Edit your hosts file to point the domain to localhost.
Then when you want to view your site, just visit the domain that you chose. If you need to modify CSS or script, just make your changes and refresh the page. If you make a code change, compile your app and then refresh the page.
If you need to actually use the Visual Studio debugger, then just attach to the IIS process (application pool name) and your breakpoints will get hit.
I've found a combination of techniques that brings my productivity up a fair bit.
Use an alternative browser like Chrome. When you stop the VS debugger and you're using IE, VS will shut down the browser, but it won't do it with Chrome (or Firefox, or anything else.)
Switched web.config to run in Windows Authentication mode and wrote a quick transparent login routine enclosed in conditional compilation tags (debug only, this feature is not perfect for our production product.)
Now when I'm getting into it I can stop the debugger (which no longer closes the browser,) make code changes, build, optionally start the debugger again, and just hit F5 in Chrome to load the latest. The refresh obviously takes longer since the app has to start up but there's no "run browser/log in/navigate back to the page" task anymore.
Hopefully this will help somebody else in a similar situation.
My main goal: make development faster by not having to wait as long each time I change the code of my site.
I'm developing an ASP.NET web application in Visual Studio 2010. While developing, I normally run the app with "Control+F5" (ie. start w/o debugging). This starts up the built-in ASP.NET Development Server. However, when I modify code and do this, I get the following:
-Press Control+F5
-The modified project(s) in my solution build
-The web-server is started (if it's not already)
-My browser opens & waits
At this point there's a 15-30 second delay before I see the first page. Reloading a page is instant, as well as modifying an .aspx page and reloading. But changing any code & recompiling causes another 15-30 second delay.
First, I'm trying to see where that time is spent (which is the point of this question). Looking at the log file, there's about 5 seconds until my global.asax.cs file runs. Then a wait of 10-15 seconds, then my Site.master.cs file runs. What is running in that time in between? What files does ASP.NET run and in what order?
Second, I can see that some of this time is spent with "csc.exe", which leads me to believe that the pages are being compiled-on-request. Can I precompile this code (again, using the built-in web server, not IIS) and will this be faster?
I'm open to other suggestions on how to make this faster. I want to minimize the time between modifying code & seeing changes on the site. There are multiple projects in this solution. One project uses the other as a reference. I'm on XP. I can use XP's IIS if that will make things faster. Any ideas?
Thnaks!
If you are curious about the internal processes and architecture of asp.net and IIS work then follow this link.. may be you will get your problem point on which you want to work.
low-level Look at the ASP.NET Architecture
and have look on this question somewhat similar to yours as Aristos comment on your question.
Slow Performance -- ASP .NET ASPNET_WP.EXE and CSC.EXE Running After Clicking Redirect Link
I have an application that runs perfectly fine locally using the VS 2010 application server, however, when I deploy to our web app machine startup just spins and spins and never loads. We have other apps on this same machine that load just fine (this is a debug deployment of same app in product).
I have been spinning my wheels on this for days and I am at a loss as the problem could be.
Here is what I did
Create a new directory (same level as other apps)
Copied over our existing test (www.domain/test/) and it works fine
Build and publish new debug app (www.domain/test/) and it just spins trying to load first form.
I know the diretory is "working" as the 'test' application I put there works fine.
If it's killing the App pool, you might get something in the event log. Fiddler (www.fiddlertool.com) is great http debug tool which let you see if you're in a redirect loop. Also Firefox shows a more meaningful error, something about exceeding the max redirect count.
It does sound like something is looping, but not quick enough to cause a stack overflow, which is odd, because you'd expect it to fail every time.
Simon
Do you have the ability to remote desktop into the machine? If so try running process explorer and look at the process details for the worker process that is giving you issues. Definitely look at the TCP connections being created. If your processor is pegged at 100%, and memory usage is rising then you probably have an endless loop running.
It sounds like it's more related to IIS than ASP.NET. What about the identity that the website is running under? Is it possible that the user the site's running under a bad user, or maybe the password needs to be re-entered?
I did a quick Bing search
There are a lot of postings regarding the error message you described above. Most if not all point to code in your app that is crashing. I know I had a similar problem when I used an automated/threaded daemon utility in my web application. Make sure your code is not bringing down the server, sometimes the VS2010 web server is a little more foregiving than an actual IIS deployment.
If that doesn't work try running a Remote Debugging Session to try and catch any errors being thrown but not handled.
Lastly you could try to setup a new local IIS server to see if you have the same problems. Scott Gu has a nice article about using IIS Express to do this.