|Subject||Re: [firebird-support] Re: How many Users FB support|
David Johnson wrote:
> On Mon, 2005-08-29 at 23:09 +0000, Adam wrote:Thanks for you answer David. Would you trust this to FB (v2)? If yes, on
>>--- In firstname.lastname@example.org, "Eduardo A. Salgado"
>>>--- In email@example.com, Carlos Ortiz Quiros
>>>>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?
>>>According to The Firebird Book, the limit per server is 1,024.
>>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
> 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.