>
>> To me that sounds like the
>> superserver WOULD be able to make use of a multi-core computer.
>>
>
> In theory, yes a multi-threaded application can use multiple cores but
> Superserver does not.

Yes and no: Parallel execution paths require that the one process (and multiple
execution threads) are present on the one physical processor. So even if
SuperServer had multi-core thread parallelism, it'd only scale to the number of
cores on your physical processor, i.e. 4.

>
>> Sigh. Multiple processors - NO. It's the one thing that people
> love to hate about SS.
>>
>> Dual-core single processor: *I* don't know, so wait for someone who
> does.
>
> Don't know for sure, but I have never seen fbserver.exe use more than
> one core at a time if that counts for anything.

When we were testing SuperServer on our blades we saw it only using 1/8th of the
available cores (2x Quad Core Xeons, Win2k3 Standard, 12GB ram)
Much happier now on Classic, which uses all cores, especially when bean counters
are doing multiple OLAP reports every morning... :-)

> If you are running a complex query in Superserver, it hurts everyone's
> performance. The same query on Classic will tie down one of the cores
> but other queries get a better look in. This has to be weighed up
> against Superserver having the benefit of a shared cache which can
> therefore be larger. Because of this, I have noticed very little
> difference on a dual core box when we look at performance between the
> two models. What Superserver loses in being tied to 1 CPU it makes up
> with by more cache hits, but as it scales out to 4, 8 and 16 core
> boxes, classic pulls a long way ahead in our experience.

I just have to add that a large cache on your SCSI controller makes a HUGE
difference to Classic - even if it's smaller than the DB size itself, having
index pages and recent records in CACHE is nice...

N.