Hello, un_spoken@...!

Friday, June 10, 2016, 10:34:01 AM, you wrote:

>>3. FB 3.0 SS - very little difference between inserting in 1 and 32
>>threads. So, this breaks myth that inserts (to one table) can be speed
>>up by splitting it to different threads
>>4. FB 2.5 SS - 32 threads are 3 times slower than 1 thread

uycuFg> That is a strange result, I assume that you did the tests on
uycuFg> a fast hard drive? I've made my tests on SSD.
uycuFg> My threads were operating on a short transactions, 100 record per transaction.

strange result - where? Firebird 2.5 SS can't use SMP, so, it
definitely work slower with parallel threads than 3.0 SMP.

uycuFg> I doubt it because it works without any problems on 2.5 SS.
uycuFg> But it does not surprise me that your tests are passing
uycuFg> because you have a different application with different performance results.

well, we did only pure inserts, in one transaction (for each thread),
and connection per one thread.
The idea of test was to understand performance of inserts to one
table, not to test SMP itself, inserts to many tables, updates, or something.
So, our results are very clean and understandable.

As we (IBSurgeon) see the latest trends, the more and more systems that
using Firebird get performance problems with concurrent resource
access -
inserting to one table from many clients
updating same table and part of data
and even selecting the same table and part of data at high load.

In this case
- Classic is the worst. Since it needs to reload modified pages from
the database, not from shared cache.
- SuperClassic is a bit better, but anyway, bad
- SuperServer is the best - shared cache do it's job. And SuperSever
3.0 is the best-best :-) because it uses SMP.

--
Dmitry Kuzmenko, www.ib-aid.com