IIS only processing one request at a time - asp.net

We have an asp.net web application that works fine in our environment. One of our partners tries to the exact same code in their environment and can only process one request at a time. For example, there is only page that calls a long running stored procedure (5 minutes). If you call that page and the try to open a new page, the new page won't serve until after the first page has completed. We can see the request back up by looking at the worker processes for their application pool. They are running IIS 8.5 on a windows 2012 server. They're also running SQL Server 2016.
The database connection is structured the same as as in our environment. The stored procedure is not wrapped in a transaction. Any ideas what might be causing this behavior?

IIS also can work in the Debug mode, when it is enabled, Asp is limited to processing one request at a time in a single-threaded manner.
Open “InetMgr” or IIS manager, double click ASP under the IIS section of the website. Check the below settings in Asp section.
See the below discussion for more information.
IIS7 - only serves up one page at a time. It's a making me crAzY!

Related

IIS 10 on WinServer 2019 is loading asp.net pages very slow even on subsequent loads

My question has nothing to do with the initial page loads. My ASP.NET Web Site is running very slow, on IIS 10. Even when I refresh the page after a load, it takes minutes. What do I need to check?
Application Initialization Module is installed and running
App Pool is using Classic managed Pipeline mode and has Start-Mode set to AlwaysRunning
Preload Enabled in Website's setting is set to true
The same application runs fine on another server running older WinServer and IIS 8. What do I need to check?
This is embarrassing. Posting this answer so I find my own question the next time I run into this again, or someone else runs into this. My application on the other server where it runs, has caching configured so all the database pulls are cached. This new server has no caching set up. Those pulls are so slow, I am finally getting the hang of it.

How to warm up an ASP.NET MVC application on IIS 7.5?

We would like to warm up an ASP.NET MVC application hosted on IIS 7.5 server. The warm up module that used to be available at http://forums.iis.net/t/1176740.aspx has been removed since sometime.
The application should be warmed up everytime IIS or ASP.NET worker-process restarts for any reason. During the warm up period, IIS should return some HTTP status code signifying its warm up state or its inability to serve any clients.
Would creating a executable that navigates through necessary pages in the site via HttpRequests be a good idea? The executable can be triggered from IProcessHostPreloadClient implementation. Is it possible to configure IIS so that it would only accept requests from localhost and once the executable is done, it can switch over to all clients - but that switch should not trigger an IIS restart (obviously).
Is it possible to use an Visual Studio 2010 - Web Performance Test to warm-up an application instead of creating an manual executable? Any other alternatives?
PS: The application uses Forms Authentication and uses sessions - so maintaining state cookie and other cookies is important.
UPDATE 1 - We are using .NET Framework 4.0 and Entity Framework (database first) in our application. The first time hits to EF queries are slow. The reason behind the warm up is to get these first time hits out of the way. We are already using compiled queries at most places and we have implemented pre-compiled views for EF. The size of the model and application is very large and complex. Warm up needs to walk through many pages to ensure that compiled and non-compiled EF queries get executed at-least once before any end user gets access to the application.
Microsoft has released a module that does exactly what you ask for. The Application Initialization Module for IIS 7.5 improves the responsiveness of Web sites by loading the Web applications before the first request arrives.
You can specify a series of Urls that IIS will preload before accepting requests from real users. I don't think you can get a true user login expereince, but maybe you can set up simulated pages that does not require login that fulfills the same warmup you ask for?
The feature I think is most compelling is that this module also enables overlapped process recycling. The following tutorial from IIS 8.0 include a step-by-step approach on how to enable overlapped process recycling.
When IIS detects that an active worker process is being recycled, IIS does not switch active traffic over to the new recycled worker process until the new worker process finishes running all application initialization Urls in the new process. This ensures that customers browsing your website don't see application initialization pages once an application is live and running.
This IIS Application Initialization module is built into IIS 8.0, but is available for download for IIS 7.5.
You may take a look at the following post for the Auto-Start feature built into IIS 7.5 and ASP.NET 4.0.
Any application that generates a server request for the hosted resources can be used to warm up an IIS process. Exactly how many requests you need depends on what parts need warming up. Typically, warm-up is used for:
Starting up a worker process. For this, you only need to ask for one resource to warm up a process for the entire application.
Perform any static initialization, database startup, or pre-caching. Anything you do in your Global.asax file will happen when you do your first request, so if you can make all of your initialization happen then, you'll still only need to make one page request.
Force pre-compilation of ASP.NET pages. For this to happen you would need to hit every page. Fortunately, this is typically not much of a time cost, so you likely don't need to worry about it. If you do have individual pages that load slowly, you can warm them up separately.
The "warm-up" process here isn't anything magical. You just need force IIS to serve the URL in question. Everything you mentioned would take care of that: using a stress-test tool to query the URL, writing a custom utility to post HTTP requests, even just scripting out a tool like 'wget' or a PowerShell script to download the URLs would do it.
As far as restricting access to localhost, as far as I know, within IIS, the only way to change that requires you to restart IIS. You could always build a pre-request hook into your application and maintain the state there, and have your warm-up process query some specific URL that toggles that state to "open". But I'm not sure what you would accomplish. If, somehow, a user did try to query your site before your warm-up finished, all that would happen is your site would take a long time to respond, then they would eventually get the page they asked for. If you locked them out of the site during warm-up, they would instead get a browser network error that claimed the site was offline, which (to me) sounds much worse.

Mixing .NET versions between website and virtual directories and the "server application unavailable" error Message

Backstory
Last month our development team created a new asp.net 3.5 application to place out on our production website. Once we had the work completed, we requested from the group that manages are server to copy the app out to our production site, and configure the virtual directory as a new application.
On 12/27/2010, two public 'Gineau Pigs' were selected to use the app, and it worked great.
On 12/30/2010, We received notification by internal staff, that when that staff member tried to access the application (this was the Business Process Owner) they recieved the 'Server Application Unavailable' message.
When I called the group that does our server support, I was told that it probably failed, because I didn't close the connections in my code. However, the same group went in and then created a separate app pool for this Extension Request application. It has had no issues since.
I did a little googling, since I do not like being blamed for things. I found that the 'Server Application Unavailable' message will also appear when you have multiple applications using different frameworks and you do not put them in different application pools.
Technical Details - Tree of our website structure
Main Website <-- ASP Classic
+-Virtual Directory(ExtensionRequest) <-- ASP 3.5
From our server support group:
'Reviewed server logs and website setup in IIS. Had to reset the application pool as it was not working properly. This corrected the website and it is now back online. We went ahead and created a application pool for the extension web so it is isolated from the main site pool. In the past we have seen other application do this when there is a connection being left open and the pool fills up. Would recommend reviewing site code to make sure no connections are being left open.'
The Real Question:
What really caused the failure? Isn't the connection being left open issue an ASP Classic issue? Wouldn't the ExtensionRequest application have to be used (more than twice) in the first place to have the connections left open? Is it more likely the failure is caused by them not bothering to setup the new Application in it's own App Pool in the first place?
Sorry for the long windedness
You'd really need to obtain and review the server's Application & System event and HTTPERR logs for the period the server was reporting these errors.
Without these it'd be hard speculate what was the root cause of the problem.
Update:
OP incorrectly tagged his question so this next section no longer applies. However I'll leave in place because I think the information is useful for those encountering these issues and perhaps thinking about migrating to IIS7.x.
You are correct that running two different .NET Framework's in the same application pool can cause these errors but that's something you'd tend to see on Windows 2003/IIS6, not Windows 2008/IIS7.
IIS7 uses a slightly different approach to specifying which .NET Framework version is loaded and it's determined by the Application pool's managedRunTimeVersion property. When requests are processed by IIS/ASP.NET the site's Handler Mapping's use a preCondition attribute to determine when to load the requisite handler (which is kind of like a script mapping in previous versions of IIS).
This mechanism prevents the incorrect runtime version being loaded into the application pool's worker process.
So if an application pool is configured to run .NET Framework version v4.0 only that version will load, even if your application is built against v2.0.
There's a great article on how this works here:
Achtung! IIS7 Preconditions
The section on Handlers about half way through explains why the dangers of accidentally loading the wrong .NET version into a pool are mitigated by the preCondition feature.
A Server Application Unavailable error usually means something catastrophic has happened (like loading the wrong ASP.NET version's ISAPI filter into an already running worker process).
Not closing SQL connections is unlikely to cause this type of serious error. You'd more than likely be seeing a yellow screen of death runtime errors if that were the case. Running out of SQL connections usually doesn't bend ASP.NET so out of shape that the whole service tops itself.
My prime suspect would be a permissions problem where the application pool identity was unable to correctly access the application folders. But it's just a hunch.
Again, what you need to do is get the Application & System event logs and the HTTPERR logs (they reside in %systemroot%\System32\LogFiles\HTTPERR. That will contain clues and facts about what went wrong.
Update 2:
On Windows 2003/IIS6, if you have two applications running different ASP.NET versions that reside in the same pool you will get this error. In my experience (I work for a web hoster) it is the primary cause of this infamous error page:
There's also a tell-tale event logged to the Application Event log:
Event Type: Error
Event Source: ASP.NET 2.0.50727.0
Event Category: None
Event ID: 1062
Date: 12/01/2011
Time: 12:31:43
User: N/A
Computer: KK-DEBUG
Description:
It is not possible to run two different versions of ASP.NET in the same
IIS process. Please use the IIS Administration Tool to reconfigure your
server to run the application in a separate process.
Whilst your root application may not be written in ASP.NET it's likely that something has triggered loading of a different version of the framework into your site's application pool.
there's a rogue web.config in the root...this will trigger ASP.NET to load
there's a wildcard mapping to ASP.NET 1.1 in the site script maps (less likely, but possible)
I'm inclined to think that your new application most certainly ended up in a pool where other sites or applications were running a different framework version. The only way to really find out is to obtain the Application event logs and look for the event shown above.
It's hard to tell; there could be many causes (too many resources used, calling outside of .NET caused something to crash, etc). I would look in the Event log and see if you can find something there.
If you're running different versions of .NET you definitely want separate pools. If you have the option, I would recommend separate pools for each application (even if in the same .NET version).
As far as "closing the connection" (I assume you mean the connection to the database). If you're creating "low level" connections (i.e. SqlConnection, SqlCommand) then make sure you're wrapping them in a "using" statement, otherwise your connection pool can fill up. In my experience though, you should receive regular .NET errors in this case. If you're using an ORM this shouldn't be an issue.
Edit:
If you can't find anything useful in the Event Log, you could try this: http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/

How to identify an iisreset in an asp.net web application?

I've got an application that needs to do some work on startup (before the first request is in).
I've added the initialization code in the global.asax file (Application_start method) but this code doesn't seem to be hit after an iis reset is performed.
Is there an event which is triggered in an asp.net application when an iis reset has occurred?
Thanks.
Application start happens on first request, not on iisreset.
The site doesn't start itself..
See "Restart cache item callback on web process restart" here.
In such cases, the service will stop
running unless a page is hit and the
Application_Start is called.
Application_Start is called only when
a page is visited for the first time
in a web project.
I would suggest having a batch file that contains iisreset and an "iexplore mypage" call
Edit: apparently, you can use application end to trigger application start. YMMV
http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
This may be of help to you.
Tho the features are new to IIS 7.5 which is only on Windows Server 2008 R2 / Windows 7.
Auto-Start Web Applications with ASP.NET 4
Some web applications need to load large amounts of data, or perform expensive initialization processing, before they are ready to process requests. Developers using ASP.NET today often do this work using the “Application_Start” event handler within the Global.asax file of an application (which fires the first time a request executes). They then either devise custom scripts to send fake requests to the application to periodically “wake it up” and execute this code before a customer hits it, or simply cause the unfortunate first customer that accesses the application to wait while this logic finishes before processing the request (which can lead to a long delay for them).
ASP.NET 4 ships with a new feature called “auto-start” that better addresses this scenario, and is available when ASP.NET 4 runs on IIS 7.5 (which ships with Windows 7 and Windows Server 2008 R2). The auto-start feature provides a controlled approach for starting up an application worker process, initializing an ASP.NET application, and then accepting HTTP requests.
Edit: Link to more information about Auto Start feature.
http://www.asp.net/LEARN/whitepapers/aspnet4#0.2__Toc253429241

asp.net mvc 2 website MUCH slower on IIS 7.5 vs built-in server

I am taking some time to learn how to develop asp.net mvc2 websites, but I'm used to working directly off IIS instead of the built-in web server that uses the random ports when you hit F5.
but I've noticed that using the built-in webserver, requests fly and are immediate. I am using only the default project with the Home and About pages as it comes out of the New ASP.NET MVC 2 Project settings, no database connections, nothing beyond the base install...
but when I setup the IIS website and pointed it to the same directory, each request takes at least 3-5 seconds to complete, sometimes more.
this isn't just the "load" on the first request. EVERY request takes this long on IIS.
but if I F5 and test the project once again, everything zips and the responses are immediate.
What might i have configured incorrectly?
this is on win7 x64 by the way
You can check with a tool like firebug what takes the longest time in the request. If you use firebug it will tell you which part of the request cycles takes a certain amount of time. (I once used this when I encountered problems with the localhost URL, Firebug told me that the DNS request took about 2 seconds while using 127.0.0.1 took 1ms (using google I found out that was an issue due to ipv6 enabled)). So try tracing the requests with Firebug.
If the request to IIS is performed quite fast and the browser is waiting for a response for a long time it must be in the handling of IIS (the built-in server and IIS are different). In that case you can try reinstalling IIS (to make sure no plugins or other data is in IIS making the site slower) by removing and adding IIS via the windows components.
If that still doesn't solve the problem try tracing on the application via the built-in tracing capabilities of ASP.NET (http://msdn.microsoft.com/en-us/library/wwh16c6c.aspx)

Resources