This problem occurs only in debug mode with my ASP.NET MVC application. In release mode, everything is ok.
In debug mode, I can pass through my login process let's say 2 out of 10 times. All I usually get is a timeout on a Linq query (EF6) applied on a 50000 rows database table. Is there any options in Visual Studio that would explain this?
It usually takes a few (long) seconds between me clicking on a button and the controller's method being called. And when I'm debugging and try to execute a linq query, I get SQL Server timeouts a lot of times.
Deleting the web site cache helps a little but something else is wrong, probably with Visual Studio itself
Related
My IIS session occasionally loses all data stored in it, it usually takes about 3-5 minutes, but definately less then the session timeout set in the web.config. The problem is not reproducible reliably, when it happens, accoring to the logs the AppPool is not recycled and the Session ID remains the same, it just loses all data. Any suggestions on how to debug this?
So far I tried to overwrite the session provider and stored the session data into a static variable, we checked all relevant timeouts and we stored a dummy value in the session, that is lost as well
A number of things can cause session state to mysteriously disappear.
Your sessionState timeout has expired
You update your web.config or other file type that causes your AppDomain to recycle
Your AppPool in IIS recycles
You update your site with a lot of files, and ASP.NET proactively destroys your AppDomain to recompile and preserve memory.
If you are using IIS 7 or 7.5, here are a few things to look for:
By default, IIS sets AppPools to turn themselves off after a period of inactivity.
By default, IIS sets AppPools to recycle every 1740 minutes (obviously depending on your root configuration, but that's the default)
In IIS, check out the "Advanced Settings" of your AppPool. In there is a property called "Idle Time-out". Set that to zero or to a higher number than the default (20).
In IIS, check the "Recycling" settings of your AppPool. Here you can enable or disable your AppPool from recycling. The 2nd page of the wizard is a way to log to the Event Log each type of AppPool shut down.
If you are using IIS 6, the same settings apply (for the most part but with different ways of getting to them), however getting them to log the recycles is more of a pain. Here is a link to a way to get IIS 6 to log AppPool recycle events:
I'm writing an ASP.NET Web API application hosted on IIS7 (no special configuration).
My problem is that for each first request (on a new machine/new browser/after a while...) there is a long delay - even on requests that return constants!
I've read about "warming up" scripts but it's not the issue here. It seems like the web server is trying to create a session and it takes very long time. Any suggestions?
EDIT
I think the delay is caused by worker-process creation for each new session. Now the question is why is it so slow, and why doesn't the web server reuse living worker-processes to serve requests?
I have configured the application pool to limit worker processes to 5 with no timeout (set to 0). This caused the first five sessions to be slow on first requests (which I can live with) and now the worker processes are alive. But surprisingly, from time to time, the request is slow again!
If you are using Windows Server 2008 R2 you could configure the Auto-Start feature on the Application Pool. Also in the properties of the application pool you should disable it from being recycled at regular intervals. Bear in mind though that while this will limit the slowness, the application pool could still be recycled by IIS. With the Auto-Start feature it will be loaded again automatically in memory, but the code in your Application_Start will be executed on the next request. So you could still observe some slowness.
Another cause can be https. Our site can run with and without https. The delay at the first page (5 to 15 seconds) occurs only with using https. This post explains the issue with https and the fix:
https issue by the MCS team
I have an ASP.net MVC 4 site and it gets slow on the first request.
It is not high slow but pages that use to long 1000-700 ms on load, the first time it longs 8-15seg. It occurs when i wait for 10 minutes for example and come back to make a request. The web site is not on production server yet. May it be when the app pool does not receive any request it goes to sleep?.
I have configured the new AutoStart mode in framework 4:
http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
I think it may be the first request to the SQL Server Express 2012 (in the same server).
I have set the autoclose=off in the database.
What more can i do?. How could i see what is going on the first request to avoid that slow response?.
Thanks to every one who has apported to this question.
Finally i think it has to do with the idle time configuration in the App pool.
It was set 5 min (default) and i have set it 60 min. and now it goes fine!
Thanks to this question:
First request is very slow after website sits idle with ASP.NET MVC 3 (IIS7)
You can compile the views for faster performance.
The documentation is for MVC 3, but it should still work:
Compile Views in Asp.Net MVC 3 with Visual Studio
i have an application which gets random session timeouts. (IIS 7.5 on Windows 2008 R2, .NET 4.0)
i tried the following:
checked the application log if the w3wp.exe process was crashed, but there is no entry.
disabled in the application pool the rapid fail protection
moved to the sql server state provider to be sure the loadbalancers sticky session is not
the problem. (we use a kemp loadmaster).
ensured that no other applications use the same application pool.
checked that exceptions in a thread of a called assembly is correctly handled. (simulated using throw new exception) and the error handling was correct.
ensured that the validationKey and decryptionKey is set in the webconfig on all 4 webservers to the same key.
i run now out of ideas how to spot this evil bug. any suggestions? i cannot reproduce the problem on my local machine in the debugger.
one point which is maybe important, the move from page 1 to page 2 where the session loss often happens, takes sometimes more than 120 seconds, because of a third party system which is connected via tcp socket.
HI Snoopy you linked to my question as they are similar,
As my appool was crashing I tried this solution. If your appool crash's this may help
http://support.microsoft.com/kb/911816
the solution stop fix hack kept my app-pool up but didn't fix the problem,
<configuration>
<runtime>
<legacyUnhandledExceptionPolicy enabled="true" />
</runtime>
If your app-pool is still intact you might try ELMAH as this helped me a lot
http://code.google.com/p/elmah/
you can use this code to get ELMAH to handle unmanaged exceptions
http://code.google.com/p/elmah/issues/detail?id=199
I am curious if it is MVC 3.0 problem with .net 4.0
as i have several very similar apps running using MVC 2.0 with no problems,
Only started when I moved to MVC 3.0
Does it happen on a single server? Sure sounds like an issue with the web-farm.
Can you alter your app so you don't use the 3rd-party app for testing?
You have to eliminate pieces until the failure goes away, then add stuff back. Restore 3rd party app, turn other servers back on, etc.
I'm having a problem with a MVC (1.0) app that I can't figure out at all. There's two versions of the site (live and UAT) hosted on the same server. For each version of the site, the same code is shared by multiple organisations who each have their own database (MSSQL2005) and a separate web site in IIS (7.5) (pointed to the same code).
The UAT site has an update to the code and the database that is waiting to be deployed to the live site.
One of the customers ("customer A") is getting an error "104: Connection reset by peer" when they try to log in to the UAT site. They can see the login page but when they submit their login details the connection seems to be timing out (the requests seem to take ~130s to complete).
Customer A can log in fine to the live site. The other customers don't have a problem logging into the UAT site or the live site. If I try to log in as customer A, using their login details, it all works fine from within our network, and also from outside our network.
Customer A seems to be using squid as a proxy.
I can't think what the problem could be, and I've run out of ideas of things to test. The fact that I can log in as the customer fine and other customers don't have any issues seems to eliminate the code and database as problems.
What other things could I do to try and isolate the problem?
By dumping out the request data I was able to work out that something (I'm guessing the proxy) was removing the form values from the request. This obviously meant the app didn't work properly.
However, it seems whatever was removing the form data was leaving content-length unchanged, which would explain why the client was timing out waiting for more data and the server thought it was finished.
By using https instead of http (which we were going to do anyway), the request tampering seem to have stopped.