Thank You very much for the information. Now for the fun
part...Testing

Todd

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...>
wrote:

>
> At 10:24 AM 1/02/2008, you wrote:
> >Adam,
> >
> >The appserver is Apartment threaded COM object. And there is no
> >bottle neck I am just trying to better understand the differences

in

> >classsic and superserver. Right now we are using IB 6 but it will
> >not scale. And for most of our client base the Interbase 2007

cost

> >is to much. I have not tried the classic version only the
> >Superserver. Superserver does fine but does not appear to take
> >advantage of the multi-processor enviroment.
>
> True. InterBase 6 is Superserver. So far, neither Firebird nor

any version of InterBase fully utilises fine-grained multi-
threading.

>
> InterBase from v. 7.1 onward can cooperate with the OS's SMP

control, which means it can avoid the intrinsic problem on Windows
where the SMP control causes the entire Superserver process to see-
saw between processors (horrible!) unless you set the process
affinity to one and only one CPU. Firebird doesn't have this
workaround so (for almost all SMP hardware platforms) you must set
the CPU affinity. It is CPU 0 by default at installation. You
should read the comments in firebird.conf (or the configuration
section of the v.1.5 release notes for more detail) to find out how
to move the affinity to a different CPU.

>
> When fine-grained SMP support is fully implemented (in Firebird 3)

the engine will fully support SMP to the degree that process threads
(roughly, connections) will be farmed out to other CPUs when
desirable. It will NOT support farming out threads within a SS
process thread.

>
> Some level of SMP support is scheduled for Firebird 2.5 although I

(for one) remain clueless about what is intended at that point of the
implementation.

>
> >Is there a problem switching from classic to superserver or vice

versa in a production enviroment?

>
> It depends what you mean by "problem". It's the same server engine

serving requests for the same database. The difference is in the
model of delivery and resource usage. You will ignore
reconfiguration issues like page buffer and page size (and others) at
your peril.

>
> >I just want to know that we can scale with Firebird and take

advantage of these multi core machines.

>
> If you want to know in black and white, chapter and verse, exact

details of scalability for *your* hardware in *your* environment for
*your* database then nobody could tell you. SS runs as a single
process and spawns threads for connections. Its total CPU resource
limit for a 32-bit process is 2 GB RAM. Classic runs as one process
per connection, each process instance having its own 2GB limit. On a
site where you have a single machine doing lots of other things
besides serving Firebird, you could be starving any Firebird server
of resources. On a network where you're doing a heck of a lot of
resource sharing besides database connections, Firebird clients could
be getting nowhere near the traffic speed they need...and so on.

>
> You really have to test and compare under your particular

conditions. You might be interested to read this white paper as part
of your research:
http://www.firebirdsql.org/devel/doc/papers/html/paper-fbent.html

>
> ./heLen
>