Subject | Re: ReTuning Firebird Server for Optimal performance |
---|---|
Author | Adam |
Post date | 2008-07-30T00:24:34Z |
--- In firebird-support@yahoogroups.com, "fabianchocron"
<fabianch@...> wrote:
documentation is in error, the new threading model that makes it
possible for Superserver to allocate a distinct CPU core per database
is new in Firebird 2.5 (Alpha).
http://www.firebirdsql.org/rlsnotesh/rlsnotes25.html
Unless you are meaning to install different Superserver engines on
different ports and setting the affinity of each so that a CPU core is
dedicated (to the extent possible under the OS) to that engine
instance (This is clearly a new user to Firebird, and installing
multiple instances in parallel is not the easiest thing in the world
to accomplish).
That too can have its advantages, as the Superserver cache is shared
between all connections, but it is slower in other cases, such as when
two connections to the same database want to do something. On Classic,
this can be allocated to multiple CPU cores to be handled
simultaneously, whereas using any Superserver model (including the new
threading model in 2.5 and the multi-instance model mentioned in the
prior paragraph), the single CPU core must be shared.
Of course one must understand that if Superserver or Classic server
was inherently superior in every way, the Firebird project would not
bother maintaining them both.
Adam
<fabianch@...> wrote:
>You are surely entitled to your opinion, however unless the
> > Tip 2: Your server is SMP, use Classic server.
>
>
> Sorry, I totally disagree!!! I have followed similar advise from this
> forum, and after going in circles for weeks went back to FB 2.1 64
> bits Super server, installing 8 instances (1 for each processor), and
> there is nothing better than that, at least for us. We have several
> databases in use, and each processor is taking care of at least 1 DB.
> We also have about 300 concurrent users.
documentation is in error, the new threading model that makes it
possible for Superserver to allocate a distinct CPU core per database
is new in Firebird 2.5 (Alpha).
http://www.firebirdsql.org/rlsnotesh/rlsnotes25.html
Unless you are meaning to install different Superserver engines on
different ports and setting the affinity of each so that a CPU core is
dedicated (to the extent possible under the OS) to that engine
instance (This is clearly a new user to Firebird, and installing
multiple instances in parallel is not the easiest thing in the world
to accomplish).
That too can have its advantages, as the Superserver cache is shared
between all connections, but it is slower in other cases, such as when
two connections to the same database want to do something. On Classic,
this can be allocated to multiple CPU cores to be handled
simultaneously, whereas using any Superserver model (including the new
threading model in 2.5 and the multi-instance model mentioned in the
prior paragraph), the single CPU core must be shared.
Of course one must understand that if Superserver or Classic server
was inherently superior in every way, the Firebird project would not
bother maintaining them both.
Adam