I have a cloud-based application where there can be up to 5000 "worker nodes" communicating with a web server. All 5000 could be started simultaneously and once online, would call an API method to pick-up a job. This API method in turn calls a SQL Server stored procedure to get the job details and return a response to the individual node. To prevent multiple nodes getting the same job, the stored procedure puts a lock on a particular database table while it executes.
Web Server is Windows 2016 Server running IIS 10.
SQL Server is Microsoft SQL Server Standard 2017
My question is how to best manage these connections through web.config or IIS settings. As far as I know, my main levers are
Max Pool Size in web.config
Connection time-out for IIS Site
I can increase the pool size to 10,000 of course and set the connection time-out to 2 or 3 minutes but I'm not sure if there's a best practice for managing something like this.
I've deployed a SignalR-based app onto my on-premises server, and it is crashing when there are more than ten concurrent users.
The long-running requests for the worker process associated with my app pool all have URLs of the form /signalr/reconnect?transport=serverSentEvents&connectionToken=....
As soon as more than ten users connect, the limit of ten concurrent requests is breached and the application hangs.
Do I need to change any IIS settings to allow SignalR to scale in this instance? If I'm deploying to Azure, how would I configure the settings to take account of this?
Workstation OSes (Windows XP, Vista, 7, 8, etc) have a limit of at most 10 concurrent connections in IIS. These OSes are not intended for use as a server (and I think the EULA prohibits it, as I recall). The concurrent connection limit is one way that Microsoft enforces the "not a server" restriction.
Windows Server OSes (Server 2008 R2, Server 2012, etc) do not have this restriction, and so you won't have this problem when you deploy you application to a production server. Windows Azure is fine also (it is Windows Server behind the scenes).
How to stop/unload a specific IIS Application (hosted within a specific Site) in order to release the server's resources?
The IIS API (Microsoft.Web.Administration) seems only to allow stopping the entire Site:
Stop/Start WebSite in IIS (6.0 and 7.0) programatically
UPDATED:
I have managed to resolve this issue via an alternative way:
Configure an Application Pool to Recycle after Reaching Maximum Virtual Memory Usage (IIS 7)
As a result, a particular pool is recycling automatically.
Put the site in it's own application pool, then just recycle that pool
I have a SharePoint web application that has some custom web parts that consume an asmx web service. This service talks to an Oracle 10g database. Currently, the service is hosted on the application server in its separate web site (and port). I think I should host it on the front end servers under the _vti_bin folder to automatically achieve high availability and load balancing of the service calls. Would you recommend this "enhancement"?
Please notice that the asmx service is configured to run in a 32 bit app pool since oracle client, which it uses, is 32 bit software. I think then I can’t just have it under _vti_bin, I may need to have it in its own virtual directory under the SharePoint application’s IIS web site and configure that VD to run in a separate 32 bit app pool. Will that work out? Will I still achieve the HA and LB benefits knowing that Windows NLB is used?
Another related question; should the service be hosted on the WFE in the first place? It hits an external database which I could think of as a middle tier service that can be kept on the application server(s); one more server to be added soon
I have a problem with timeouts in IIS. In the web.config the session timeout was set to 60 minutes but after 20 minutes the session ends.
This problem only occurs in IIS7 and not in IIS5.
After some investigation, I discovered it was due to the application pool's timeout. If the App Pool is left 20 minutes without doing anything, IIS ends the session.
If the application is using the defaultAppPool this always happens but if I change the App Pool to the classic .NET App Pool, the timeout does not occur.
Both modes have idle timeout but only in the DefaultAppPool this occurs.
Why is this?
What is the difference between be a Classic .NET AppPool and DefaultAppPool?
What is the difference in the pipeline, between Classic and Integrated?
IIS7 has some major changes to better support WCF and one of the key pieces is the new integrated application pool. This session from PDC talks about some of these challenges from the perspective of making WCF services perform better: http://channel9.msdn.com/pdc2008/TL38/
This page has a good overview of IIS7 architecture: http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/.
I've included some of the key information from this article on the purpose of the two different kinds of app pools below:
Integrated application pool mode
When an application pool is in
Integrated mode, you can take
advantage of the integrated
request-processing architecture of IIS
and ASP.NET. When a worker process in
an application pool receives a
request, the request passes through an
ordered list of events. Each event
calls the necessary native and managed
modules to process portions of the
request and to generate the response.
There are several benefits to running
application pools in Integrated mode.
First the request-processing models of
IIS and ASP.NET are integrated into a
unified process model. This model
eliminates steps that were previously
duplicated in IIS and ASP.NET, such as
authentication. Additionally,
Integrated mode enables the
availability of managed features to
all content types.
Classic application pool mode
When an application pool is in Classic
mode, IIS 7.0 handles requests as in
IIS 6.0 worker process isolation mode.
ASP.NET requests first go through
native processing steps in IIS and are
then routed to Aspnet_isapi.dll for
processing of managed code in the
managed runtime. Finally, the request
is routed back through IIS to send the
response. This separation of the IIS
and ASP.NET request-processing models
results in duplication of some
processing steps, such as
authentication and authorization.
Additionally, managed code features,
such as forms authentication, are only
available to ASP.NET applications or
applications for which you have script
mapped all requests to be handled by
aspnet_isapi.dll. Be sure to test your
existing applications for
compatibility in Integrated mode
before upgrading a production
environment to IIS 7.0 and assigning
applications to application pools in
Integrated mode. You should only add
an application to an application pool
in Classic mode if the application
fails to work in Integrated mode. For
example, your application might rely
on an authentication token passed from
IIS to the managed runtime, and, due
to the new architecture in IIS 7.0,
the process breaks your application.
The classic pool processes the requests in the app pool by using seperate processing pipelinesfor IIS and ISAPI. integrated uses an integrated pipeline, IIS and ASP.NET a(better performance) takes advantage of the improved features of IIS 7.0 using only the one process.
Good practise is to create a new application pool for each application, then configure sepeerately according to application requirements.
Classic mode follows the steps below :
1.The incoming HTTP request is received through the IIS core.
2.The request is processed through ISAPI.
3.The request is processed through ASP.NET.
4.The request passes back through ISAPI.
5.The request passes back through the IIS core where the HTTP response finally is delivered
Integrated mode uses:
1.The incoming HTTP request is received through the IIS core and ASP.NET.
2.The appropriate handler executes the request and delivers the HTTP response
Increase the session timeout in web.config as per
remember increasing this causes the application to consume more resource, eg memory
I think your question has the answer in it. IIS 6 and 7 have a concept of Application Pool timeout, this is different from session timeout.
What is the difference between modes ... already addressed. I'm uncertain about how your questions regarding pipelines and differences in modes relate to your problem - the timeouts.
Some perspective: Idle timeout won't occur on a web site with any traffic. You've probably got a problem that only occurs in a QA site or your dev box. The idle timeout setting exists to save resources on your dev box and $5/month hosting companies with lots of underused web sites (e.g. my blog). You probably do not want idle timeout on a public site.
Session timeout - set in web config, if a user doesn't hit the server, their session times out.
Idle timeout Noone touches the web server at all for 20 minutes, so shut down to save resources. In IIS 6, this is on the performance tab of the app pool - and is easy to disable. In IIS 7, you can set in in application pool advanced settings or in the processModel element. I don't run as much IIS 7 as IIS 6, but it looks like removing the element from web.config, or setting to 0, gets infinite idle timeout.
The DefaultAppPool ignores settings for session timeout in web.config, but ASPNet App Pool will use the settings in web.config.