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