RAD Studio survey
There is a new RAD Studio (Delphi,etc) survey on-line, from Embarcadero. Firebird is mentioned so, go ahead and participate if you use Delphi, CBuilder, etc.
There is a new RAD Studio (Delphi,etc) survey on-line, from Embarcadero. Firebird is mentioned so, go ahead and participate if you use Delphi, CBuilder, etc.
IBSurgeon just published an article about How to install Firebird 3.0 (snapshot build) on Windows. There are some differences compared to previous Firebird versions, so everyone should read this.
This article, from Dmitry Yemanov, is a must read for everyone using Firebird on more recent Windows versions, specially Windows 2008. As some people already experienced, it seems that the Windows Cache Manager intelligence in those versions of Windows are not smart enough, and can produce very bad performance for database access in some circumstances.
From Dmitry Yemanov:
The project roadmap has been updated a bit. The change is to boost the v2.1.5 and v2.5.2 releases at the cost of slightly delaying the v3.0 Alpha release.Firebird 2.1.4 was released exactly one year ago, so now it’s a promised time for v2.1.5. It has 53 bugs fixed and no critical issues remaining unresolved. Firebird 2.5.1 was released more than 5 months ago and the expected release date for v2.5.2 is approaching the next month. It has 45 issues resolved up-to-date and a few more are in the pipeline. So it makes a lot of sense to release them sooner rather than later.
The v3.0 Alpha release will be going through the preparation stage while all three release candidates (v2.0.7, v2.1.5, v2.5.2) are being field tested, so it’s likely to appear shortly after the aforementioned releases, in the second quarter.
Thanks for your understanding.
The Firebird Project team is happy to announce that the v2.0.7 release candidate kits for Linux, Windows and Mac OS X platforms are ready for testing.
The download page:
http://www.firebirdsql.org/en/firebird-2-0-7-rc1/Enjoy the testing and please don’t hesitate to report the found regressions (if any) in the Firebird-Devel list or in the bug tracker.
Regards,
Dmitry
The technology trends we have described put SSDs in an unusual position for a cutting-edge technology: SSDs will continue to improve by some metrics (notably density
and cost per bit), but everything else about them is poised to get worse. This makes the future of SSDs cloudy: While the growing capacity of SSDs and high IOP rates will make them attractive in many applications, the reduction in performance that is necessary to increase capacity while keeping costs in check may make it difficult for SSDs to scale as a viable technology for some applications.
Not good news, specially for those thinking about using the for critical work, like database servers.
Read full research here (in English). Short article in portuguse here.
New Firebird case study from wobe-systems GmbH, German software development house for the graphics industry.
“…A production database of 100 GB and more containing BLOBs is nothing unusual at our customers sites…”
“.. Firebird SQL server is at the core of our system helping our customers swift and safely through their daily work. Equipped with near zero administration and ample possibilities of scalability Firebird SQL database offers an operational reliability that does meet the requirements of industrial and time critical applications.”
Read full article here.
From http://ramsees.blogspot.com:
I did some comparitions selecting 1000, 10000 and 100000 with Ruby Fb gem, Delphi Fibplus and the FB .NET driver, here is the result:
ROWS | RUBY | DELPHI | .NET |
1000 | 0.12 | 0.47 | 0.09 |
10000 | 0.94 | 0.48 | 0.53 |
100000 | 10.95 | 3.79 | 5.53 |
The results are on milliseconds, the table is from a production database with 40 fields and about 3 million records, as you can see, native code is still the king, .NET result are quite good, but Ruby is quite dissapointing handling lots of data.
It was just released the first webinar video from the Mind the Bird campaign. The webinar is about the history of Interbase and Firebird, by Ann Harrison.
The parameter TcpRemoteBufferSize found in firebird.conf is supposed to set the maximum size of a packet being transfered. The default value for Firebird is 8K, and the maximum accepted is 32767. Theoretically, bigger packets should make the transfer of large resultsets faster (mostly noticed when connection is high latency networks, aka internet).
Recently, I did some tests with this parameter, but wasn’t able to find any differences in the time of a fetchall with a select first 2000 * from some_table_with_no_blobs_and_lots_of_records. A similar test that I did last year, with different FB version and O.S. showed a speed increase of almost 3x in the fetchall time when the packet size was set to 32K, but seems that I cannot reproduce this with my current environment anymore.
If you have some time, please do some tests with this parameter, and publish the results in the comments of this post. Remember to test changing the value at client, at server, and at both, and to mention what Firebird version was used (at server, and client library too, if different). Also, I recommend to run the first select/fetchall at last one time before getting the results, to fill Firebird and O.S. cache and get more accurate results.
If you are a “hardcore” user, you may also want to install Wireshark and have an inside view of the communication process.