On 15-6-2016 17:55, chen hsu chenxuz@... [firebird-support] wrote:

> Thanks, Helen. Please see my replies inline.
>
> I am sure it is not 3.0 specific, 2.5 is the same. and the main issue is
> scalability, sequential transaction performance is actually pretty good,
> comparable to ESE store on windows I was comparing firebird against.
> but when running multiple transactions in parallel, ESE perf increased
> from 4 tx/sec to 26 tx/sec (128 byte/record, 200 records per
> transaction, 6 transaction threads on 6 cores, which I expect the best,
> logical cpu/ht is not very useful performance-wise), while firebird
> decreased. These transactions do not write-conflict with each other.
>
> The basic flow of our code is like, first the main function creates a
> database connection, and spawns multiple threads, passing in the
> database connection. Each thread does this: create a transaction using
> the db connection, do insertion of data, and commit the transaction.
> Each thread measures its own elapsed time.

I did a similar test against FB 3 on Windows (against localhost, 1000 tx
per thread, 100 inserts per tx, using a single prepared statement), and
the difference in results are quite dramatic.

Using super server and 8 threads (I have a quad core with 8 logical
processors), I get +/- 12.7 transactions per second per thread (or 101
tx per second).

With classic I get +/- 3.4 transactions per second per thread (or 27 tx
per second).

With superclassic I get +/- 3.8 transactions per second per thread (or
30 tx per second).

I used a table with a bigint primary key (generated identity) and
char(128) character set octets. Removing the primary key column increase
throughput for super server by +/- 40%, for classic server only 17%, for
superclassic only 15%.

Mark
--
Mark Rotteveel