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.
Related
If I F5 to debug, and browse to my test site using Chrome, and execution halts before sending a response (e.g. we get an exception and I click Stop Debugging instead of continue to the end), that Chrome window and any child windows it spawns will no longer work with the project. It will say "Loading" with the spinner in the tab, the window will be empty, and it will stay like this apparently forever. Alternately, in a new tab, I type the URL and hit enter and it does not display any loading behaviour as though it isn't even trying to load it. This persists across tabs within the same window hierarchy.
My workaround is to create incognito windows in Chrome when testing local sites. If it gets into this error state, then I have to close the window and open a new incognito session from the original browser parent. If I accidentally cause this problem in the main window, I have to fully close Chrome to proceed. Using different Chrome profiles also works as I assume it's a different top level process.
Otherwise, it does seem to calm itself after quite a while - 5+ real life minutes or something similar it will revert and start working again and the page will load if it was still trying. But is there a better solution? This is VS 2022, debugging ASPX/C#, using a hosts file for local.site.com domains and separate http/https ports.
Edit: Image to show settings page
Your issue is rare, we need to troubleshoot step by step. First, please confirm that Tools==>Options==>Debugging==>General==>Enable Edit and Continue is enabled. Then you need to use detach all instead of stop debugging.
Well, if you hit a break-point in code behind, then code has haulted, and no more web pages can be dished out. (this is standard behavour when using the built-in web server that launches by hitting F5. if you close the web page, then the web server shuts down, debugging stop, and you back into Visual Studio.
You could try hitting ctrl-F5. That runs the VS site as non debug mode, and break-points etc. thus don't usually get hit. But, f5 STARTS a copy of IIS express web server. You close that web page, then debugging stop, IIS is then shut down. This is correct behavior's.
If you want to start testing the web site with say NOT having a debugger tied to the web site, then you probably are better off to install + run IIS full edition, and not the Express Edition that is "tied" to VS and the debugger.
So, the instant you close the browsesr, or even hit the "stop" button in VS, then IIS is shut down - it is stopped each time.
However, you could/can give ctrl-F5 a try - that will launch your site as non debug mode (and you not that no stop button is highlight).
IIS "express" is a great setup for f5, step code, debug code. However, the instant you want to start testing the site, and not having launched it from "inside" of VS? Then you probably should setup a VM with the full edition of IIS, or even I suppose install full edition of IIS on your computer (I not done that, since I have a few VM's, and I don't want to "mess up" my developer box with having a full pop full edition of IIS installed on my computer.
So, if you want "others" to test the site, then setup a VM with server 2019, or whatever, and then install IIS full edition. This THEN gives you the full GUI and setup features of a web server - which is a good learning experience.
So when using f5 to debug? yes, a halt in code will halt the ability of the web server to dish out other pages. In effect, IIS process one page at a time, and when the page life cycle is done, the the next page/request can be processed.
So, if you want "more" then this setup, then you probably need/want to get a full blown full edition of IIS up and running. And I suggest that should be placed on some other computer then your dev box, or at the very least in a VM on your dev box.
You "can" sort of get IIS Express edition to be launched and running outside of a VS debug session, but it is painfully, since you don't have the GUI and all of the web configuration tools that the full edition of IIS has.
I have a very strange problem I'm fighting with since VS 2015 (maybe even 2013).
Now I'm working with VS 2017 and it still occurs.
Here is the situation.
I have a legacy web application (Webforms, later enhanced by integrating webapi REST with javascript/html client code, some WCF endpoints, etc).
I build and start debug session from within VS (I do debug/testing mostly with Chrome and FF, rarely with IE/Edge/etc.), and I use IIS Express.
Most of the time the application debug session starts just fine - the page loads in browser and I can either debug server side in VS / client side in browser's debug tools.
But sometimes, the page actually never completes loading, and no matter how long I wait, it just stays locked on "loading..." message.
The only solutions I found are:
- either restart PC
- or (in Chrome), start browser in new identity.
- switch to a different browser (e.g. after starting with Chrome, open page in FF - or vice-versa).
When the page loads normally, the VS's Output Debug window displays various tracing / debug messages or progress of loading various dlls.
However, as soon as the problem described above starts to happen, the VS Output Debug starts to log msgs like
The thread <#nnnn> has exited with code 0 (0x0).
When this starts to happen, no matter what I do (except starting browser in new identity / change browser / restarting PC) I can no longer debug.
No matter if I totally close and restart the browser, clear cache, close and restart VS / IIS. Nothing helps.
The situation mentioned above occurs at very random intervals.
Sometimes I can work and debug for days (I suspend / hibernate the PC at the end of the day, resume next days, end everything works ok).
However other times the issue occur after just starting few debug sessions, and on occasions, even after a full shutdown / restart, at very first debug session, this happens.
I have lived with it for long time, but sometimes is very annoying.
Anyone have experienced a similar issue?
Any idea what is causing it, and is there is any fix / workaround?
Thank you
The messages in your output log reporting:
The thread <#nnnn> has exited with code 0 (0x0)
Just indicates that the thread has exited safely and is very normal to see this in correctly working code. In fact it would be abnormal to not see this as you will end up using all available threads.
From what you have explained I would suggest that you need to look at the extensions you have installed in your browsers. I typically will use a vanilla profile (blank profile with no modifications / extensions) so that my debugging is not affected by any modifications the extensions can make.
I would also monitor your system's CPU and memory usage. Are either of these being maxed out?
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
We have an application which, on startup, populates it's cache from an csv. This takes about 1 minute. We thought putting an application warm up on it would eliviate the problem, but it seems like the requests specified are not being executed. Hitting the application locally will take a minute and then be instant thereafter. I tried several requests, relative (to localhost and application root) and absolute ones, to no avail. It does not work after stop/starting the corresponding app pool, nor recyclying (if there is a difference to application warm up), nor rebuilding the application.
Anyone have suggestions I could try?
Edit: The event viewer does not have anything related to the application warm up (as far as I can tell) and Application_start() is not called
if you're not seeing warmup requests in your logs perhaps you don't have them enabled in your application settings? What language are you using? (Warmup requests are enabled by default for all Java applications.)
I see entries for /_ah/warmup in my logs.
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.