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
