David
Sun May 06 23:45:26 CDT 2007
On May 5, 3:33 am, bert <b...@photobert.com> wrote:
> On May 5, 1:22 am, "Ken Schaefer" <kenREM...@THISadOpenStatic.com>
> wrote:
>
> > IIS 6.0 has a tuning mechanism that determines how many threads it needs to
> > service incoming requests.
>
> > I'm not sure what exactly you were told, so it's a bit hard to comment on
> > the accuracy of that comment.
>
> > Cheers
> > Ken
>
> Ken,
>
> There are two situations I'm trying to determine the outcome of:
>
> 1. If 10,000 users have active sessions at one time, if IIS will be
> able to handle all 10,000 sessions.
> 2. Assuming no load balancing and a server with four processors, If
> 500 users request an ASPX page at the same time will IIS max out it's
> threads and return a "Server not available"?
>
> Thanks,
> Bert
1. Depends on your definition of "session"
2. Depends on the ASPX application performance characteristic
Actually, for the sort of answers you are looking for, you will need
to give far more details about your application architecture and your
definition of "session" since it is application centric, not IIS
dependent.
However, I can tell you that IIS6 will not be the bottleneck with the
sort of numbers that you are talking about. Your server-side
application is the far greater question. And when you are talking
about "extreme" performance tuning, it really comes down to how well
you know your server-side application works (and whether it adversely
interacts with IIS6). Raw IIS6 performance, by default, easily handle
your requirements.
For example, IIS6 efficiently handles requests asynchronously, meaning
it can handle arbitrary number of requests (bound by system memory
resources) while using barely any threads. The concept of asynchronous
IO is very hard for most people, including Apache, *nix users, and
most developers, to understand -- hmm, I should write a blog entry
about this at some point, to make things conceptually clearer...
Most people comprehend synchronous IO because the number of
simultaneous requests depends on the number of threads synchronously
handling IO for each request. So, to handle 10,000 connections/
sessions at a time requires 10,000 threads. However with Asynchronous
IO, you can handle 10,000 connections/sessions at a time with only two
threads and suffer no performance consequences ASSUMING the request
processing itself is asynchronous. However, as soon as the request
processing is synchronous in nature, you quickly revert back to
synchronous behavior of needing one thread per request IO.
Thus, when you talk about "IIS max out it's threads" you are really
talking about "the server-side application improperly tying up IIS's
threads" -- which is really a scalability bug with the server-side
application and not IIS's ability to scale -- though from a casual
observer's perspective, it looks like IIS does not scale without
adding more threads. This is a *very* common user misconception for
many reasons (users believe their code is perfect and IIS/Microsoft
code is crap, users cannot distinguish the performance of each
component, users do not understand performance/CS concepts in
general). To me, I know it is a scalability problem with the server-
application and a perception problem with the user. You want to read
the following blog entry to get a understanding of the basic issue.
http://blogs.msdn.com/david.wang/archive/2006/03/14/Thoughts-on-Application-Pools-running-out-of-threads.aspx
As for your metric using 500 users requesting an ASPX page at the same
time --
1. Is it for a cold or warm ASPX page (i.e. has the worker process
already started and JIT'd CLR. has the ASPX page already loaded once
before)
2. Is the ASPX performing synchronous operations that tie up the CLR
Thread Pool
Basically, you can view the ASPX scenario as ASP.Net asynchronously
queuing those requests onto its own queue and using CLR Thread Pool to
execute the request -- so IIS threads are not consumed, max'd out, nor
is IIS going to return "Server unavailable" -- all requests are
asynchronously outstanding upon the completion of the CLR threads used
by ASP.Net, no IIS threads are consumed nor maxed out. However,
depending on the performance characteristics of the ASPX page, its
operations may consume the CLR Thread Pool and cause 503/500 errors to
be returned by ASP.Net when it cannot handle its own request queue.
Once again, to the casual observer's perspective, it looks like IIS
does not scale, but the truth is very different.
I'll stop at this point and wait for you to indicate how you want to
proceed.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//