Does IIS 7 have some limit of simultaneous requests? I'm using Windows Server 2008.
Thanks in advance.
Yes, IIS 7 can have a limit of simultaneous requests, depending on the edition of Windows you're using. I see people often assert (as others have here) that somehow the limits have been lifted with IIS 7. It's just not always so, and depends on whether running 2008, 7, or Vista.
Let's start with Win2k8, since you mention using that. The following document suggests that 2k8 has only a server version, and with no limits. "With Windows Server 2008, IIS 7.0 ...there is no request execution limitation." (source: http://learn.iis.net/page.aspx/479/iis-70-features-and-vista-editions/)
That page also shows a table with other versions, but though it's not clear, those apply to Vista. Here are the limits for IIS 7 (from that table) on those versions: Basic & Starter editions: 3 requests, for Premium: 3, for Pro: 10, and for Server: unlimited.
I've found similar limits, documented here: http://technet.microsoft.com/en-us/library/cc268241.aspx. "With Starter and Home Basic editions of Windows Vista, the simultaneous request execution limit for IIS is three for Windows Vista Home Premium. ...For Windows Vista Business, Enterprise, and Ultimate edition...the simultaneous request execution limit is ten. ..With server editions of Window, IIS 7.0 has no request execution limit."
Finally, while I've not found a document stating the limits for Windows 7, I have confirmed the same limit of 3 on my copy of Windows 7 Home Premium. (It's curious that the learn.iis.net page above does discuss both Vista and Windows 2008, but makes no mention of Windows 7.)
With respect to this limit, if it's a problem for you or other readers, here's a potentially valuable bonus tip that I've not seen documented anywhere: the limit is really per application pool, or more technically per worker process. So you can certainly get more request simultaneously against your box by using multiple app pools.
But perhaps you want to have more requests against a single site, which obviously can be connected only to a single app pool. There's still good news: you can increase the number of worker processes per app pool in the "advanced settings" for a given app pool (right-click on the app pool), increasing "Maximum Worker Processes" from the default of 1. (Some will recognize that as being the same as what was known as "web gardens" for app pools in IIS 6.)
For those new to them, whether creating new app pools or more worker processes for an app pool, for each new worker process, you'll see a new w3wp.exe in task manager.
Finally, there's a caution to consider if you decide to increase the number of worker processes. At least back in IIS 6, I documented that if you're running an ASP.NET app using sessions that are "inproc" (or in memory), the default, there is a problem with using multiple worker processes (web gardens), in that the sessions are not replicated among the worker processes. That may not be an issue for the OP, so I'll say you can learn more at an entry I did a few years ago: http://bluedragon.blog-city.com/lost_sessions_webgardens_sessionstate.htm.
On Windows Server operating systems, IIS 7.0 has no request execution limit.
Source
The limitations by default are the capacity of your server to serve those requests (i.e. CPU, memory) although you can set up throttling etc based on a number of concurrent users.
Related
I am finding that when I turn on the "Enable 32-bit applications" parameter in an application pool, while also using an out-of-process state server, the session state is not maintained across worker processes (as though IIS is ignoring my state server configuration and using inProc). There are specific reasons for this application why I need both 32-bit enabled and multiple worker processes (there is a Crystal Reports library which I must call which operates in 32-bit, and that same library has some nasty process blocking which will halt access to the rest of the site if there aren't multiple worker processes).
I verified the basics (multiple browsers: Firefox, Chrome, IE, Edge, and Safari), triple-checked the state server config (running, tcp port correct, machine keys configured in IIS, TCPIP loopback:42424 as the target, etc). I made a dummy 1-page project just to save a GUID under the session state whenever no previous GUID is known, and then did an ajax refresh showing the GUID and worker process ID and I can see that each process ID returns different a different GUID (GUID follows process ID). It really seems like IIS ignores the out-of-process state server as soon as the 32-bit applications switch is flipped. Any information appreciated on how to fix this problem.
Edited to add: I just put my little test site on a 2012 R2 server and the problem did not occur. It seems to be a problem in IIS 10 / Server 2016.
I have a website written in .Net 4.5, MVC 4, using SignalR 2.0.2 with the Redis backplane for load balancing. This also has a number of actions to return json to the app. It's set to pre-load and app pool set to always running. Hosted on Windows 2012, IIS 8, using AWS Redis ElastiCache.
I am saving the connection ids into my SQL database against the user on the OnConnected, OnReconnected, and clearing with OnDisconnected, but these all have try/catch just in case.
We have an iOS app written to connect via websockets. Unfortunately the app does not close off it's connections and creates them more often than needed.
The net effect is that the server can have 3000+ connections, but only a few hundred are real connections. This is not really an issue in itself, and will be fixed in the next app release.
The problem is when the code is updated or the app pool recycles (regular intervals) the CPU maxes out for a long time. I have not had this happen with any other website i have written, and this is the first SignalR site with so many connections, so i believe that the server is trying to gracefully handle all the connections.
The effect is that the whole website is unavailable. Doing an IISRESET fixes it, obviously. Does not matter if the system is running on 1 server or 2.
So, knowing that this version of SignalR does not support disconnecting clients from the server-side...
Does anyone know why this would happen?
Is there anything i can do about it, except for killing the website with iisreset?
If any more info is required, please ask.
Long time reader, first time poster.
Thanks
There is an ASP.NET application with a set of web services, and there is a WinForms application that calls these web services.
The w3wp.exe (which handles asmx calls) run special processes that do a really "hard" jobs (like zipping, xml parsing, etc.). It is a long story why we need it to be done in separate processes and why we don't run this code inside w3wp.exe - this doesn't matter here. It must be like that.
If multiple requests came simulteneously from many users, there can be 30-40 such processes, and they consume CPU. They consume it so much that almost no CPU resources is left for IIS itself.
So, the problem is next: when the following HTTP requests are coming to this IIS, IIS cannot handle them: it cannot even pass them to w3wp.exe because server is "bombed". And, as a result, in peak time 30 users have run their queries, and 31st user is getting a WebException in the WinForms client "timeout expired".
I have found a lot of articles in the internet which explain how to tweak IIS, but noone take into account the fact that OTHER processes and/or applications can run on the same machine. And noone tells what to do to make so that IIS is of higher priority.
So, the question is next: is there a way to "explain" IIS that it should start by default the apppool (svchost.exe) and w3wp.exe with hiher priority?
I faced this issue in Windows Server 2008 r2.
I had a windows service (which used parallel processing) which used to bloat up my CPU a lot & left nothing for IIS & SQL Server.
So I set processor affinity to the windows service to consume only specific processors.
You get in Task Manager->RightClick Process -> Set Affinity.
This left other processors free to use for SQL & IIS.
To an extent, It decreased the productivity of the windows service which was now working with a limited set of processors but it did not matter that much.
My environment: Windows Server 2008, IIE 7.0, ASP.NET
I developed a Silverlight client.
This client gets updates from the ASP.NET host through a WCF web service.
We get 100% CPU usage and connection drops when we have a very low number of users (~50).
The server should clearly be able to handle a lot more than that.
I ran some tests on our DEV server and indeed 100 requests / s maxes out the CPU.
What's odd is that even if the service is replaced by a dummy sending back hardcoded data the service still maxes out the CPU.
The thread count looked very low at about 20 so I thought there was some contention somewhere.
I changed all configuration options I could find to increase the worker threads (processModel, httpRuntime and the MaxRequestsPerCPU registry entry).
Nothing changed.
Then I stopped the IIS server and ran the web service as a console (removing all the ASP authentication references).
The service maxed out the CPU as well.
Then comes the magic part: I killed the console app and restarted IIS and now the service runs a 5-60% CPU with 100 requests / s and I can see 50+ worker threads.
I did the same thing on our preprod machine and had the same magic effect.
Rebooting the machines keeps the good behaviour.
So my question is: what happened to fix my IIS server? I really can't understand what fixed it.
Cheers.
Find out the root cause of the high CPU usage, and then you can find a fix,
http://support.microsoft.com/kb/919791
I have a ASP.NET web application running on an IIS6 server. The application is making potentially long running calls to a xml service on a remote machine. Some of the service calls on the remote machine are taking a long time to execute (sometimes up to 4 minutes). The long term solution would be to make the calls asyncronous, but as a short term solution we want to increase the timeout for the calls and the overall httpRequest time out.
My fear with this is that the long running calls will fill up the request queue and prevent the "normal" page requests from completing. How can the server, IIS and application settings be tuned to temporarely resolve the issue?
Currently there are approximately 200 page requests/minute and this results in 270 service requests/minute.
The current executionTimeout is 360 (6 minutes)
The current service call time out is 2 minutes
There's this article on Microsoft's Knowledgebase that has some pretty much all the information you might need:
* Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications
I will give you some research I have done regarding some of the specific items handled in the article above. This information below applies to IIS6, comments for IIS7 where applicable.
Increase the Processor Worker Thread pool from 25 to at least 100
The default values for the Threadpool size is 100 because the default value for autoConfig is true.
The values covered by autoConfig is
maxWorkerThreads
maxIoThreads
maxConnection
There is one value that is still 25 that must change is – ASPProcessorThreadMax, this can only be set in the IIS metabase (via adsutil tool) in IIS6. [IIS7’s equivalent is the processorThreadMax value]
So I'm opting not to change the machine.config settings as they are fine and there are other paramaters that would be affected by turning off autoconfig, but rather change ASPProcessorThreadMax from 25 to 100 via the IIS metabase (the only way to change this value).
e.g.
cscript %SYSTEMDRIVE%\Inetpub\AdminScripts\<nowiki>adsutil.vb</nowiki>s SET W3SVC/AspRequestQueueMax 100
Max connections per server
maxconnection
The autoconfig sets this value to 12*number of cpu’s, that’s how many connections can be made to each address you are connecting to at one time.
Debugging
Here are some things you can do:
Monitor if requests are waiting in the queue
Monitor the following counter:
Run perfmon
Add counter: ASP.NET Applications/Requests In Application Queue
This will show us if work items are queued because of a shortage of workers.
Check Identity Used by Application Pool
Open IIS Manager
Check which application pool is used by your site in IIS manager.
Choose the Application pool being used in the Application Pools list, then Right Click -> properties and see what account identity is being used.
It should be Network Service by default.