Subject | Re: [firebird-support] General concensus on possible issue |
---|---|
Author | Woody (TMW) |
Post date | 2005-06-24T19:37:26Z |
From: "Myles Wakeham" <myles@...>
In most case, AFAIK, this is generally caused by bad transaction design in
an application. Long running transaction tie up the record versioning that
Firebird uses. The more versions it needs to keep up with, the more work it
has to do. That's a simplistic way of explaining it but Helen and many
others here can jump in with further information. Also, correct indexing
techniques and proper use of stored procedures can be a big improvement in
the speed of communicating data to/from the server.
Woody (TMW)
> I have been monitoring the forums regarding a potential issue withFirebird
> 1.52 Super Server, and I believe that it is not an issue relatedis
> specifically to the database server software, but to the way in which it
> used.appeared
>
> A collegue of mine recently stopped using Firebird for a mission critical,
> transactional application because they found that the performance of the
> database was good most of the time, but in some cases the database
> to have 'stalled' and was taking 30 seconds or more to process a simplebox.
> query. This seemed to coincide with the CPU on the server running at 100%
> utilization with Firebird taking the majority of the horsepower of the
In most case, AFAIK, this is generally caused by bad transaction design in
an application. Long running transaction tie up the record versioning that
Firebird uses. The more versions it needs to keep up with, the more work it
has to do. That's a simplistic way of explaining it but Helen and many
others here can jump in with further information. Also, correct indexing
techniques and proper use of stored procedures can be a big improvement in
the speed of communicating data to/from the server.
Woody (TMW)