| Subject | Just a few words about Firebird 3.0 performance. |
|---|---|
| Author | |
| Post date | 2016-06-09T10:50:59Z |
Hello
First of all I wanted to say that my post has no intention to diminish the value of new Firebird version.
I was in Prague last year on Firebird conference (very nice event BTW) but even then there were doubts how well FB 3 performs in comparision to FB 2.5. As far as I remember there were two presentations with examples regarding perfromance and both were indeterminate - sometimes FB 2.5 behaved better or similar.
Few days ago I've decided tu put FB 3.0 under test on a real business application which is working for 24/7.
This application is reading data from PostgreSQL database (stored in JSON), parses the data, inserts it to Firebird database and then scans the inserted data and inserts some additional information. (Proccess of scanning the data must be separated from initial inserts).
Here are the tests results for 80000 records stored in PostgreSQL.
|Test|2.5 CL 1 THR|2.5 CL 4 THR|2.5 SS 1 THR|2.5 SS 4 THR|3.0 CL 1 THR|3.0 CL 4 THR|3.0 SS 1 THR|3.0 SS 4 THR|
| Time(s) | 201 | 285 | 169 | 107 | 221 | 321 | 216 | 112 |
How to read the tests:
2.5 CL 1 THR - Firebird 2.5, Classic, 1 Thread.
3.0 SS 4 THR - Firebird 3.0, SuperServer, 4 Threads.
Tests were performed on 32 bit version and no configration changes has been made with one except: CpuAffinityMask = 255
Tests were made on my dev machine, locally. I've had all unnecessary processes turned off. But these werent a tests made with a "laboratory" precision.
However I think you can see here some pattern which may suggest that tests are close to the reality.
That is not everything:
3.0 SS 4 THR - In my opinion behaved unstable. There were lost connections to database and threads had to reconnect. At first I thought it is a coincidence so I've repeated the test and it happened again.
Firebird 3.0 Classic also did not pass my standard test suite in terms of interrupting a query. The test is implemented in a way that I create a big loop in a stored procedure. I call this procvedure from my program and then I try to interrupt query via separate thread. It works without any problems on Firebird 2.5 but in 3.0 it is not or is it much slower and timeout for my test occured. I haven't check the reason very thoroughly.
Ok that is all, if you have any comments or toughts how to improve Firebird performance let me know.
best regards.
First of all I wanted to say that my post has no intention to diminish the value of new Firebird version.
I was in Prague last year on Firebird conference (very nice event BTW) but even then there were doubts how well FB 3 performs in comparision to FB 2.5. As far as I remember there were two presentations with examples regarding perfromance and both were indeterminate - sometimes FB 2.5 behaved better or similar.
Few days ago I've decided tu put FB 3.0 under test on a real business application which is working for 24/7.
This application is reading data from PostgreSQL database (stored in JSON), parses the data, inserts it to Firebird database and then scans the inserted data and inserts some additional information. (Proccess of scanning the data must be separated from initial inserts).
Here are the tests results for 80000 records stored in PostgreSQL.
|Test|2.5 CL 1 THR|2.5 CL 4 THR|2.5 SS 1 THR|2.5 SS 4 THR|3.0 CL 1 THR|3.0 CL 4 THR|3.0 SS 1 THR|3.0 SS 4 THR|
| Time(s) | 201 | 285 | 169 | 107 | 221 | 321 | 216 | 112 |
How to read the tests:
2.5 CL 1 THR - Firebird 2.5, Classic, 1 Thread.
3.0 SS 4 THR - Firebird 3.0, SuperServer, 4 Threads.
Tests were performed on 32 bit version and no configration changes has been made with one except: CpuAffinityMask = 255
Tests were made on my dev machine, locally. I've had all unnecessary processes turned off. But these werent a tests made with a "laboratory" precision.
However I think you can see here some pattern which may suggest that tests are close to the reality.
That is not everything:
3.0 SS 4 THR - In my opinion behaved unstable. There were lost connections to database and threads had to reconnect. At first I thought it is a coincidence so I've repeated the test and it happened again.
Firebird 3.0 Classic also did not pass my standard test suite in terms of interrupting a query. The test is implemented in a way that I create a big loop in a stored procedure. I call this procvedure from my program and then I try to interrupt query via separate thread. It works without any problems on Firebird 2.5 but in 3.0 it is not or is it much slower and timeout for my test occured. I haven't check the reason very thoroughly.
Ok that is all, if you have any comments or toughts how to improve Firebird performance let me know.
best regards.