David Johnson wrote:

> Although no one has responded directly to my original question about
> scalability,

Err, you asked a number of questions that would have required a lab and
dedicated performance analysts to answer. The funding for the this
project comes from contributions and covers things like regression
testing, managing a web site, kit building, and verification. No
hardware, no labs, no staff of performance analysts. Our data is
anecdotal and historical.

> The "classic" model defines the heavy weight vertically scalable
> configuration for firebird.

Classic is better for SMP, at the moment. Each classic connection
maintains its own page cache, which puts some limits on its performance,
as "hot" pages - pages that are used by many connections bounce from
cache to cache, going through disk.

Superserver was designed to be a higher performance alternative on
single processor systems because of its shared cache. However, it's
threading model allows only one active thread at a time. On SMP
systems, it must be tied to a specific processor or most of the
processing time disappears into swapping the image between processors.

When the application runs on the same system as the database, classic
has a huge performance advantage because it runs in the application
process context. Database calls are subroutines, not process switches.

> The "superserver" model defines a light weight scaling configuration
> that is most appropriate for environments that are architecturally more
> similar to the Intel hyperthreading model, or at least dis-similar to
> the VAX cluster architecture.

No, Superserver works best on a uniprocessor where the application code
resides on a different machine. Hyperthreading does it no good.

> Superserver will allow a well built
> application to function against a lighter weight server instance, with
> only a limited performance penalty.

Because classic runs best when the application and database code share
process space, a classic application must be more carefully built. The
separate process space required to use Superserver isolates the database
from vagaries of client memory references. The server available with
classic is lighter weight than the Superserver, but you get one instance
per connection.

> Superserver is less robust, and
> demands that application code pay more attention to thread safety since
> connections and connection resources tend to be pooled.

Superserver does not pool connections - several interface layers
(Jaybird for one) do. Neither classic nor Superserver allow a client to
run parallel requests in different threads against the same connection -
the connection maintains some request context. Both allow parallel
requests if the threads maintain separate connections.

>

Now add Vulcan to this mix. Vulcan is a branch off the early Firebird
V2 tree which changes the SuperServer threading model. As with
InterBase and other versions of Firebird, each request in Vulcan is a
thread, but Vulcan threads run in parallel within the same server
process. Shared data structures are protected by a mutex, allowing n
readers or one writer. In earlier SuperServers, the server itself
controls thread execution. Vulcan relies on the system thread scheduler.

Vulcan also refactors the architecture. Firebird has one code base that
can be built in three different models - classic, embedded, and
SuperServer - using conditional code. Vulcan has one code base that
builds a set of components that can be configured in various ways to
work like any of the three models. Multi-threading is part of the
access provider, so even in its local "classic" mode, an application
that makes multiple connections can run requests in parallel.

At the same time, both Firebird 2 and Vulcan have addressed some of the
performance liabilities inherited from InterBase - the garbage collect
thread being one.

The larger answer to you question of architectures is that you don't
have to choose. Firebird has one API that works for all architectures -
if you don't like the behavior you're seeing with SuperServer, you can
change to classic just by installing a different kit - or with Vulcan,
by changing the configuration files on your existing installation. To
change to local classic or embedded, you just link to a different
library with Firebird - or make another change to the configuration of
Vulcan. Nothing in your application changes.

Regards,

Ann