> 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.

> 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.

>
> > And
> >you said that the classic model creates a new PROCESS for each
> >connection, which sounds like the less efficient model for a
> >multi-core since threads are more lightweight than processes.
>

Yes, a thread is more lightweight than a process, but as classic
creates a process for each connection, the OS can put the particular
fb_inet_server.exe process on whatever core it so chooses at any given
time.

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 tend to favour classic, but there are some nice aspects to
Superserver too. The point is that if one particular architecture was
superior in every case, the other would not be maintained.

Adam