I really dont remember if I was able to retest with > 32K, but I found this message that suggests that the effect of changing this parameter is different with FB 2.5 compared to 2.1:
--------------------- 21-Dec-2011 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 DS> 16.10.2013 14:58, Alex Peshkoff wrote: >> Telling true I do not remember it... >> But quite possible. DS> Most likely my memory doesn't serve me well. Google shows me only thread where Carlos DS> H. Cantu tested it up to current limit and got 3x speed up, then DE suggested to test it DS> beyond the limit and then all was over. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
