You are both right.

I think it is important to separate the "road map" from the "here and
now".

"Here and now", Classic will cause less grief when multiple
processors or hyperthreading is involved. Because each connection is
allocated a different process, it makes it easier to allocate just
one connection to a separate CPU (logical or physical).

Superserver uses threads for each connection within one process,
which is a lot more efficient for single processor systems. It is
also potentially more efficient for multiple processor systems too,
which is why the roadmap is that the superserver
implementation "replaces the Classic implementation". Back in the
real world, there are some teething issues with superserver and
multiple processors, so currently, if that is your environment, run
classic.

Perhaps the IBPhoenix document is a bit strong at that point, but it
really doesn't matter because both use the **same** API. Just install
the classic server if the superserver doesn't work for your setup. I
definately agree with Nigel that you can't claim a product doesn't
scale until you set it up correctly for your requirements. In fact,
all that would be needed is a little help balloon in the installer
(windows environment here) explaining when to use classic and when to
use superserver. At the moment a firebird newbie may get confused as
to what to install, and may install the wrong type.

Adam





--- In firebird-support@yahoogroups.com, "Nigel Weeks" <nweeks@e...>
wrote:

>
>
> > Hi Nigel
> >
> > We choose to use the Super Server version of FB based on the
> > following
> > information at
> >
> > http://www.ibphoenix.com/main.nfs?

a=ibphoenix&page=ibp_ss_vs_classic

> >
> >
> > "The Classic implementation predates the SuperServer
> > implementation, and
> > the SuperServer implementation is the future of InterBase.
>
> And this is exactly right, until you run it on Multiple CPU

machines...

>
> Don't decide that Firebird doesn't scale, until you've tried all

server

> architectures...
>
> Nige.