[firebase-br] Para quem possa interessar....

[Carlos H. Cantu]

This is a forwarded message
From: Ann W. Harrison <aharrison em ibphoenix.com>
To: firebird-support em yahoogroups.com
Date: Wednesday, February 9, 2005, 3:47:45 PM
Subject: [firebird-support] Scalability principles: Can someone confirm or correct ...

===8<==============Original message text===============

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