I was trying to use dedicated connection for each thread, and it seems a little
better than one connection for all the threads, but not much, the performance
line is still going down hill from single thread to multiple threads, with
SuperClassic or Classic.
I did not try Super mode before, since my project might have multiple processes
open a same database.. but anyway I had a try this time too. it looks better
than Classic/SuperClassic, going up from 5 (single thread) to almost 10 tx/sec
(12 threads).
My project used Ese database at Windows side, the performance is pretty close
to what you tested with Firebird. I got around 28 tx/sec with 8 threads. Have
you got chance to run your test on Linux?
To: firebird-support@yahoogroups.com
From: firebird-support@yahoogroups.com
Date: Sat, 18 Jun 2016 10:40:04 +0200
Subject: Re: [firebird-support] performance issue with firebird 3.0 embedded on
linux
On 15-6-2016 17:55, chen hsu chen...@outlook.com [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
