Ann
> I might also have mentioned that sharing caches and other internal structures
> between simultaneous threads is one challenge.
So the above mentioned changes have been implemented in FB3. And the was
referred as true SMP in the white papers about FB3. Correct?
> Distributing queries across processors is another and totally different
> challenge. The Firebird developers were wise (in my opinion) to take the
> challenges one at a time.
And the above mentioned task was not implemented in FB3.0, Correct? Do you know
if it planned to be implemented in FB 4.0?
Don't take me wrong, I am very happy about Firebird's quality and performance,
I was just expecting the hole SMP issue to be resolved or enhanced in FB 3.0,
hence my surprise when I did not see the hole CPUs jumping on a query.
Cheers,
Fabian
----- Original Message -----
From: Ann Harrison aharri...@ibphoenix.com [firebird-support]
To: firebird-support@yahoogroups.com
Sent: Thursday, May 26, 2016 5:41 AM
Subject: Re: [firebird-support] Re: Is Firebird 3 ready for Production?
On Wed, May 25, 2016 at 2:53 PM, Ann Harrison <aharri...@ibphoenix.com> wrote:
On Wed, May 25, 2016 at 1:11 PM, fabia...@itbizolutions.com.au
[firebird-support] <firebird-support@yahoogroups.com> wrote:
Now on the flip side, the performance sucks, it is worst than with FB
2.54, and when looking at the task manager on windows it appears only one
processor it doing the job, as if the code was not SMP enabled.... very
strange.
One possibility is that you're testing V3.0 SuperServer single user. In
V3.0, Firebird is multi-threaded at the client statement level. It does not
decompose queries and schedule the pieces on different processors. That means
that a full-table scan runs on only one processor. Two simultaneous full-table
scans will run on two processors.
I should have continued to say that two full-table scans probably won't be
any faster in 3.0 than they were in 2.5 because you're measuring disk transfers
and adding processors doesn't make the disk go faster. I might also have
mentioned that sharing caches and other internal structures between
simultaneous threads is one challenge. Distributing queries across processors
is another and totally different challenge. The Firebird developers were wise
(in my opinion) to take the challenges one at a time.
Good luck,
Ann
