--- In firebird-support@yahoogroups.com, Rajesh Punjabi <rajesh@i...>
wrote:

> Maybe I did not communicate this right, but the client (our

application)

> has been stress tested with Oracle and MySQL with InnoDB

transactions

> and is able to process hundreds of concurrent requests and for days

in a

> stress test environment without any performance degradation. With
> Firebird, the degradation is apparent in about 30 minutes.

Rajesh, can't you clear what is the queries in your testing
application? Firebird can show described performance degradation in
situations:

1. Presence of long running transaction (especially concurrecy and
absolutly except read_commited read) when intensive data modification
is made in another transactions, even if this transaction do nothing
(records versions which are garbage for all another transactions are
hold because they theoretically can be required for this transaction
if it will suddenly decide to make something).
2. Very intensive data modifications, such as updates or deletes of
millions records - garbage collection thread consume resources.
3. Intensive updates of indexed columns.
4. Existance of large amount of duplicates in indexed columns and
usage of such an indices in queries.
5. None-indexed filtering on large tables.
6. Bad choice by optimizer indices to use and order of tables joining
in complex joins (for FB1.5 unlikely, optimizer is significantly
improved but who knows).
7. Large (I mean really large) fetches from long tables.
8. Sorting/grouping/counting/taking distinct on large cursors.

Seems I did'nt forgot anything. If mentioned reasons are excluded,
degradation is not because of Firebird. You mentioned 19 sec simple
query on fresh small database. This amazed me. What is this query,
what plan is generated by optimizer? On my twice weaker computer this
time is reqired to count 1 000 000 records table in database used for
read and write by 30 connections.

Best regards,
Alexander.