--- In firebird-support@yahoogroups.com, "Eduardo A. Salgado"
<eas@o...> wrote:

> --- In firebird-support@yahoogroups.com, Carlos Ortiz Quiros
> <carlosaortiz@y...> wrote:
> > Hie you all.
> > I would like you tell me your experiences about the
> > number of concurrent users FB can support, and how
> > many resources does it take?
>
> Carlos,
>
> According to The Firebird Book, the limit per server is 1,024.
>
> -Eduardo

Sort of,

I think you will find that is the limit of concurrent connections. With
connection pooling and a proper n tier model, you should be able to
handle significantly more than that. I am sure David may have a good 2c
on the issue

The amount of resources it takes depends on lots of things, and whether
you are talking about hardware resources or administration resources.
Hardware wise, I have found it to be surprisingly efficient with the
exception of the "over the wire" TCP connections. Of course this can be
used in conjunction with Zebedee or equivalent to improve dramatically.
Hard disk wise may be a consideration, Firebird NEVER gives allocated
space back to the OS, so the fdb file NEVER shrinks (unless you backup-
restore). It will re-use space from garbage collected deleted records
etc, so it will not grow indefinately (unless you don't manage
transactions and you keep deleted record versions "interesting" and
prevent the record being flagged as garbage).

Administration wise, you will probably never need to touch the thing
after it is set up, with the possible exception of having to rescue a
limbo transaction in a failed two phase commit.

Of course, if you fail to manage transactions (ie. keep them as brief
as necessary, and hard commit or rollback rather than just abandoning
the connection), then the garbage is kept to a minimum, and performance
is predicable and constant.

The only time I have ever experienced the server process crash is with
a faulty UDF.

My 2c
Adam