On Mon, 2005-08-29 at 23:09 +0000, Adam wrote:

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

I always have 2c, and sometimes non-c too. :o)

While do have immediate first hand experience with large scale systems,
and I am very interested in scaling Firebird, my experience with large
scale Firebird installations is still theoretical. :o(

Many systems are bound by the number of available sockets. Using a good
mid-tier with an appropriately sized connection pool, you can
conceptually handle many thousand times that number of concurrent users
that the database layer will directly support. Whether or not you can
physically handle that is another question.

The system I normally work on is considered large by most standards - we
support roughly 8,000 real-time users and some unspecified number of
real-time and batch processes. We run over 1,000,000 transactions per
hour at peak times.

The underlying DBMS that we are using (not Firebird) supports only 500
concurrent connections. An efficient mechanism for pooling resources is
a necessity, not a luxury. Along with this comes the necessity of an
application level security model, separate from the DBMS security model.
Many large shops are trying to implement LDAP based security, and
commercial DBMS vendors are starting to understand the need for a more
comprehensive model than SQL92 will provide. Until LDAP plugins are
available for DBMS's in general, this will remain a necessary evil.

Designs are made so that locks are never held during selects (a problem
with locking architectures but not a problem with Firebird), and cursors
are never held open while waiting on a user to perform editing of data.
In our vocabulary, a long-running transaction is one that is a second or
more in length. In Delphi apps, we use TClientDatasets in briefcase
mode operation. In web apps, we use cached prepared statements and
DAO's.

Standards are in place defining order of update operations on table so
no deadlocks can occur. I generally recommend alphabetical order
because it is easy to remember and implement, and it does not require
maintenance of reams of paperwork.

Retry logic, where required, is measurably cheaper in CPU, memory, and
DASD resources than holding locks.

Hope this helps.