| Subject | Re: [ib-support] Firebird performance is really poor |
|---|---|
| Author | David Zvekic |
| Post date | 2003-04-11T18:48:48Z |
What are you doing during your transactions? a transaction can be many different things. I have
transactions which takes many minutes to complete.
The question is: what exactly is the test that you are performing?
Are you preparing an SQL statement during each transaction, and unpreparing and repreparing that SQL statement
each time?
Taking 100 milliseconds to prepare and optimize an SQL statement would not suprise me at all.
The question then is. do you really need to unprepare that statement, or can you reuse it.
more info is needed
Also:
deadlocks are not a bug (in the database server anyway).
A deadlock occurs when user 1 tries to modify ROW A, User 2 tries to modify ROW B, and then either
User 1 tries to modify ROW B
or
USER 2 tries to modify ROW A.
Neither user could ever possibly get their work complete because both users are waiting on the other
user to complete their work which they can't ever complete because they are also waiting on the other.
Interbase (and presumably firebird) would report this as a Deadlock error and rightfully so. It would cause one or both
of the users to unblock and report the error.
This is not a bug.
How would you have Firebird handle this situation?
What is the specific error message you are getting, and what is the exact situation under which it occurs.
more info needed
DZ
david_vanc wrote:
transactions which takes many minutes to complete.
The question is: what exactly is the test that you are performing?
Are you preparing an SQL statement during each transaction, and unpreparing and repreparing that SQL statement
each time?
Taking 100 milliseconds to prepare and optimize an SQL statement would not suprise me at all.
The question then is. do you really need to unprepare that statement, or can you reuse it.
more info is needed
Also:
deadlocks are not a bug (in the database server anyway).
A deadlock occurs when user 1 tries to modify ROW A, User 2 tries to modify ROW B, and then either
User 1 tries to modify ROW B
or
USER 2 tries to modify ROW A.
Neither user could ever possibly get their work complete because both users are waiting on the other
user to complete their work which they can't ever complete because they are also waiting on the other.
Interbase (and presumably firebird) would report this as a Deadlock error and rightfully so. It would cause one or both
of the users to unblock and report the error.
This is not a bug.
How would you have Firebird handle this situation?
What is the specific error message you are getting, and what is the exact situation under which it occurs.
more info needed
DZ
david_vanc wrote:
> Hi, all. I am running some performance tests against Firebird, and to
> be honest, it really stinks. For a single client I am getting only
> around 10 TPS. I am sure I must be doing something wrong.
>
> First, let me be clear, I don't want to do a test with write-through
> turned off, because it is crucial that data is guaranteed to be there
> if Firebird goes down. Writing to disk after a commit is not
> acceptable for my application.
>
> But the other thing that appears to be happening is with more than one
> client, I immediately get deadlocks.
>
> Is there a way to configure Firebird to improve its overall
> performance without turning off write-through? Is there a way to get
> rid of the deadlocks?
>
> Thanks,
>
> David
>