David Johnson wrote:

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

Thanks for you answer David. Would you trust this to FB (v2)? If yes, on
which hardware?

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