I ran more tests tonight, and results were very different from the past year test.
FIRST TEST (using the same server as last year test) ========== Last year test: Firebird 2.1.1 (SuperServer - linux) in server and FB 2.1.x Windows in client Tonight test: Firebird 2.5.1 client, and same remote server as last year First run used TcpRemoteBufferSize = 8K (the default), and second run used TcpRemoteBufferSize = 32767 at client. I can't change fb.conf at this server. No difference in the fetchall time! SECOND TEST =========== Another test, this time connecting to one of my customers server, internet connection by cable modem. Server is 2.5.1 (SuperClassic Linux) and Client is 2.5.1 (Windows). Access by OpenVPN. As I have root access to this server, I was able to change the value of TcpRemoteBufferSize in the server and, of course, in the client. I tested: Server x Client 8K 8K 8K 16K 8K 32K 32K 8K 32K 32K The fetch times were almost identical in all the above configurations :( The number of records returned was about 3.500, and average time was about 11 seconds. I restarted the server after every change at (remote) fb.conf. I also ran the select 2 times before getting the fetchall times, the first run was just to fill FB and disk cache. Is there any chance that FB 2.5.1 is ignoring this parameter? How to explain such different behavior compared to the last year test (FB 2.1) ? PS: Last year test I used ZeosDB app as I wish to compare MySQL to FB. Tonight test I used tool built with "FIBPlus". Also, the database used this time was not the same as the last year. Anyway, this doesn't matter, since what is being questioned is the fact that this time, the parameter changing didn't make any difference in the featchall time. I'm also trusting that on Windows, the client library will use the fb.conf located at the directory pointed in the FB registry key. []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br DY> 14.12.2011 20:02, Carlos H. Cantu wrote: >> Vlad, 06/12/2010 16:24:51: >> could you edit firebird.conf at both client and server hosts and set >> TcpRemoteBufferSize = 32700 >> ? >> >> ok, much better (but still worse than MySQL): >> [06/12/2010 16:27:47] Opening FB Query and fetching all data () >> [06/12/2010 16:27:53] End fetching FB data (6,312) >> [06/12/2010 16:27:53] Opening MySQL Query and fetching all data () >> [06/12/2010 16:27:56] End fetching MySQL data (2,89) DY> This implicitly suggests that a bigger value of the network packet could DY> improve the performance even more, perhaps down to the MySQL's almost DY> three seconds. DY> AFAIK, the default packet size in MySQL is 1MB, the maximum is 1GB. Our DY> default is 8KB and maximum is 16KB. DY> I would suggest to increase the default and remove the upper limit (or DY> make it "big enough") and then ask Carlos to re-run the same test with DY> bigger settings (64KB, 128KB and so on) and report back the results. DY> Dmitry ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
