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

[Otto]

Muito bom.
Para mim foi de especial interesse o trecho:

"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."

e especialmente a linha
"Superserver does not pool connections - several interface layers (Jaybird
for one) do" já que estou aprendendo a usar o Java (+ Firebird).

[]'s
Otto

----- Original Message ----- 
From: "Carlos H. Cantu" <listas em warmboot.com.br>
To: <lista em firebase.com.br>
Sent: Wednesday, February 09, 2005 5:31 PM
Subject: [firebase-br] Para quem possa interessar....


> 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
>
>
>
>


----------------------------------------------------------------------------
----


______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br