| Subject | Re: [Firebird-general] Re: Just a few words about Firebird 3.0 performance. |
|---|---|
| Author | Dmitry Kuzmenko |
| Post date | 2016-06-10T10:00:59Z |
Hello, un_spoken@...!
Friday, June 10, 2016, 12:35:56 PM, you wrote:
uycuFg> Not in my case, that why it is strange. I mean in your test
uycuFg> 2.5 SS is worser than 2.5 Classic.
where? I said that
FB 2.5 SS degrades 3 times from 1 thread to 32 threads.
FB 3.0 SS does not degrade from 1 thread to 32 threads
And that CS works bad.
For CS 2.5 performance dropped from 7 to 15 times for 32 threads.
And as I said, it is expectable.
Yes, SS 2.5 is fast, for example, 9 seconds to insert 1mln records in
1 thread, while SS 3.0 is slower - 22 seconds for 1 thread.
But at 32 threads 2.5 SS used 28 seconds, while SS 3.0 from 1 to 32
threads float around 24 seconds.
uycuFg> I've set up CPU
uycuFg> AffinityMask and as far as documentation says, it allows to
uycuFg> process on multiple cores.
Firebird 2.5 SS uses cores only for queries to different databases.
It never could use more than one core for one database, until 3.0.
So, setting affinity for 2.5 SS is completely useless
uycuFg> And in my Case 2.55 SS was two
uycuFg> times faster on 4 threads than 2.5 Classic.
yes, it's faster. because Classic does not have shared cache, and
each process forced to re-read changed pages from the database.
So, 2.5 SS is faster even using only 1 core, than Classic at several
cores.
uycuFg> 30000 record per one transacion per one thread is quite a lot
what about 1mln records in 25 seconds per one transaction? :-)
uycuFg> (I mean about the case of 32 threads). That might be the cause
uycuFg> of a slow down. When I was testing with different thread
uycuFg> counts I've found a sweet spot around 4-6 threads (on my i5 machine).
Your test is different. For example, if you used mix of
insert/update/select statemens, they will show different performance
on accessing one or different resources. Select itself will "speedup"
test results, because it is more lightweight then insert or update.
If you will try to update same records several times in one
transaction, you will see huge slowdown, but due to another reason
than writing to one page.
--
Dmitry Kuzmenko, www.ib-aid.com
Friday, June 10, 2016, 12:35:56 PM, you wrote:
uycuFg> Not in my case, that why it is strange. I mean in your test
uycuFg> 2.5 SS is worser than 2.5 Classic.
where? I said that
FB 2.5 SS degrades 3 times from 1 thread to 32 threads.
FB 3.0 SS does not degrade from 1 thread to 32 threads
And that CS works bad.
For CS 2.5 performance dropped from 7 to 15 times for 32 threads.
And as I said, it is expectable.
Yes, SS 2.5 is fast, for example, 9 seconds to insert 1mln records in
1 thread, while SS 3.0 is slower - 22 seconds for 1 thread.
But at 32 threads 2.5 SS used 28 seconds, while SS 3.0 from 1 to 32
threads float around 24 seconds.
uycuFg> I've set up CPU
uycuFg> AffinityMask and as far as documentation says, it allows to
uycuFg> process on multiple cores.
Firebird 2.5 SS uses cores only for queries to different databases.
It never could use more than one core for one database, until 3.0.
So, setting affinity for 2.5 SS is completely useless
uycuFg> And in my Case 2.55 SS was two
uycuFg> times faster on 4 threads than 2.5 Classic.
yes, it's faster. because Classic does not have shared cache, and
each process forced to re-read changed pages from the database.
So, 2.5 SS is faster even using only 1 core, than Classic at several
cores.
uycuFg> 30000 record per one transacion per one thread is quite a lot
what about 1mln records in 25 seconds per one transaction? :-)
uycuFg> (I mean about the case of 32 threads). That might be the cause
uycuFg> of a slow down. When I was testing with different thread
uycuFg> counts I've found a sweet spot around 4-6 threads (on my i5 machine).
Your test is different. For example, if you used mix of
insert/update/select statemens, they will show different performance
on accessing one or different resources. Select itself will "speedup"
test results, because it is more lightweight then insert or update.
If you will try to update same records several times in one
transaction, you will see huge slowdown, but due to another reason
than writing to one page.
--
Dmitry Kuzmenko, www.ib-aid.com