Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raise limit and default value for TcpRemoteBufferSize [CORE4245] #4569

Open
firebird-automations opened this issue Oct 16, 2013 · 2 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @aafemt

Carlos H. Cantu' s two years old experiment showed that 32k buffer speed up big fetches three times.

@firebird-automations
Copy link
Collaborator Author

Commented by: @aafemt

Torrents use 16k as the size for a piece. Perhaps, it has some rationale behind...

@firebird-automations
Copy link
Collaborator Author

Commented by: @WarmBooter

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant