Help testing TcpRemoteBufferSize parameter

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.

Jason Wharton talks about FBConference 2011

All,

I would just like to report to the IBO community that the Firebird Conference in Luxembourg was a great success. There were over 60 people in attendance and the sessions I attended were all very good. It’s amazing what is being done with Firebird and what is coming in the future. Things are looking very good. The IB Objects session was well attended and it felt like some useful things were learned even by some of the long-time customers. If anyone is interested, the entire session was recorded. I can see about getting permission to put it up on YouTube or to post an MP3 download of it on a file sharing site. Send me a private email.

I think most of the fun we had was getting a personal contact with all the people we rub cyber shoulders with every day. Hopefully in the future there will be more people to come and attend.

I would like to stress the importance of everyone who uses Firebird to consider being a member of the foundation. Your opinions truly matter and your financial contributions are an investment in Firebird’s success. All of those who develop Firebird are awesome people. I really enjoyed getting acquainted with them personally. I wish for them to have the means to be compensated financially for their efforts in Firebird. It could be a significant and justified temptation for them to get hired away from their efforts. The best way we can keep their brilliance and talent solely dedicated to Firebird is to give it the resources to secure their interests.

I am working on an idea to give a discount to all those who are members of the Firebird Foundation so if you have some ideas please let me know. I would like to be a strong supporter of Firebird as best I can so I am looking for ways to accomplish this.

Kind regards,
Jason Wharton
www.ibobjects.com

Source: http://tech.groups.yahoo.com/group/IBObjects/message/45720

Firebird + EXT4 + barrier 1/0 + FW ON/OFF

Philippe Makowski did some TPC tests and posted the results at fb-devel:

Hi,

I’m a bit puzzled by the results I get I made test on Fedora 16 with Kernel 3.1.1-1.fc16.x86_64 on LVM2 Logical Volume of 10G

Firebird 2.5.1 Classic

hdparm  /dev/vg_tests/testfb
/dev/vg_tests/testfb:
multcount     =  0 (off)
IO_support    =  1 (32-bit)
readonly      =  0 (off)
readahead     =  8 (on)

hdparm -Tt /dev/vg_tests/testfb
/dev/vg_tests/testfb:
Timing cached reads:   12976 MB in  2.00 seconds = 6496.46 MB/sec
Timing buffered disk reads: 174 MB in  3.02 seconds =  57.53 MB/sec

database : 1,8G
created with -w20
and buffers 1024

Episode 1: Fishbowl Database Security Basics (application that uses Firebird)

Here are the security notes for an application that uses Firebird:

Another thing to keep in mind while securing your database: sometimes when we release new versions of Fishbowl, it upgrades your database to a new version, as well. When this happens, Fishbowl makes two different backups. One is a copy of the database; the other is a Firebird database dump. I like to call these the “Murphy’s Law backups” because you shouldn’t need them, and you won’t need them – until you don’t have them. They are created for rollback purposes during the upgrade. Leaving these unprotected is just as bad as leaving your main database unprotected. You can find these files in C:\Program Files (x86)\Fishbowl\database\data – inside the “old” and “backup” directories.

1 21 22 23 24 25 84