Subject Re: [firebird-support] Re: Is Firebird 3 ready for Production?
Author
Post date 2016-05-26T12:38:01Z

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 -----
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 <aharrison@...> wrote:
On Wed, May 25, 2016 at 1:11 PM, fabianch@... [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