|
Home > Archive > IIS Server > July 2005 > IIS SMP Perf
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Our web server is a brand new dual opteron machine running win2k3. Right now
our sites run under the same app pool, which is setup with a max of 1 worker
process. We run a lot of legacy COM code, unfortunately, so it may be the
case that increasing the number of worker processes would cause issues.
Given this, would it make sense, performance wise, to split up each web site
into a different app pool? Logically I would think having more than one app
pool would mean the system could divide up work among the processors, giving
us better perf. But I'm not familiar with the internal workings of IIS. Any
tips would be appreciated.
Thanks.
| |
| Pat [MSFT] 2005-06-27, 5:53 pm |
| Processor work is split at the thread, not the process level. So, in terms
of parallelism it won't necessarily get you much.
That said, there are resources that are per process (e.g. the Process Heap,
BSTR cache, etc.) that _if they are blocking_ would benefit from the
segregation. This is very much a per-application implementation issue, so
you would need to test and as always your mileage will vary.
I have seen apps increase throughput 2-->3x by segregating just a COM object
to a separate COM+ server application (intense string manipulation) and I
have seen throughput decrease 10% doing the same thing (lots of very short
lived and simple method calls). It was just how & what the COM object(s)
did, how hard the server was being pushed, and what the ASP pages were
doing.
Pat
"axis" <none@none.com> wrote in message
news:42c007f0$1@news.microsoft.com...
> Our web server is a brand new dual opteron machine running win2k3. Right
> now our sites run under the same app pool, which is setup with a max of 1
> worker process. We run a lot of legacy COM code, unfortunately, so it may
> be the case that increasing the number of worker processes would cause
> issues. Given this, would it make sense, performance wise, to split up
> each web site into a different app pool? Logically I would think having
> more than one app pool would mean the system could divide up work among
> the processors, giving us better perf. But I'm not familiar with the
> internal workings of IIS. Any tips would be appreciated.
>
> Thanks.
>
| |
|
| We have a few COM objects that take a few seconds, so the site may see an
improvement in isolating it into different app pools.
Are there any documents online with best practices for IIS and SMP systems?
Thanks for the response!
"Pat [MSFT]" <patfilot@online.microsoft.com> wrote in message
news:eyBQPsyeFHA.1044@TK2MSFTNGP10.phx.gbl...
> Processor work is split at the thread, not the process level. So, in
> terms of parallelism it won't necessarily get you much.
>
> That said, there are resources that are per process (e.g. the Process
> Heap, BSTR cache, etc.) that _if they are blocking_ would benefit from the
> segregation. This is very much a per-application implementation issue, so
> you would need to test and as always your mileage will vary.
>
> I have seen apps increase throughput 2-->3x by segregating just a COM
> object to a separate COM+ server application (intense string manipulation)
> and I have seen throughput decrease 10% doing the same thing (lots of very
> short lived and simple method calls). It was just how & what the COM
> object(s) did, how hard the server was being pushed, and what the ASP
> pages were doing.
>
>
> Pat
>
>
> "axis" <none@none.com> wrote in message
> news:42c007f0$1@news.microsoft.com...
>
>
| |
| Pat [MSFT] 2005-07-04, 5:58 pm |
| There isn't anything you need to do. ASP was designed from the start to use
a thread pool (for IIS5 - #Threads = #CPU*25), and all of the benchmarks
were done on 1, 2, 4, & 8 way systems.
From my experience the issues that need to be considered when moving from a
single-->SMP system is that code (any code) running on a SMP system must be
'tighter'. Meaning that you can get away with sloppy coding on a single
proc with little impact but the impact will increase exponentially with the
# processors. It is not unusual for a multi-proc system to go slower than a
single proc b/c the code had many blocking functions.
For example, if you use the include <adovbs.inc>, you are causing 100+
variables to be allocated and freed (of which very few are used). This
isn't a big deal on a light load site and is unlikely to be a measurable
impact. On a multi-proc, heavy load site this can cause some pretty severe
context switching and perf hit.
For COM objects written in VB, a common issue is string concatenation. For
example:
strMyString = "This is my string <br>" <--OK and fast
and
strMyString = "This is my string" + vbcrlf <--Bad, causes 6 lock/unlock
operations for the same net result
Pat
"axis" <none@none.com> wrote in message news:42c1be52@news.microsoft.com...
> We have a few COM objects that take a few seconds, so the site may see an
> improvement in isolating it into different app pools.
>
> Are there any documents online with best practices for IIS and SMP
> systems?
>
> Thanks for the response!
>
> "Pat [MSFT]" <patfilot@online.microsoft.com> wrote in message
> news:eyBQPsyeFHA.1044@TK2MSFTNGP10.phx.gbl...
>
>
|
|
|
|
|