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

Add support for Windows 8/2012 fast/low-latency "TCP Loopback Fast Path" functionality [CORE4563] #4880

Closed
firebird-automations opened this issue Sep 29, 2014 · 13 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Sean Leyne (seanleyne)

Block progress on DNET726
Relate to CORE5679

Votes: 3

Windows 8/2012 introduced new "TCP Loopback Fast Path" feature which improves the performance of the TCP stack for "localhost" (ie. loopback) connections, by "short-circuiting" the TCP stack for local calls. The details of the new function and the code changes required can be found at http://blogs.technet.com/b/wincat/archive/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path.aspx

Commits: 6edb5af 4efe7ce f8d39e0

@firebird-automations
Copy link
Collaborator Author

Commented by: @mrotteveel

Note that this needs to be both in client and server to work.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Mark,

sure, therefore i think there should be corresponding tickets for Jaybird and .Net provider too

@firebird-automations
Copy link
Collaborator Author

Commented by: KS (karlox)

According to this article:

http://mysqlserverteam.com/mysql-5-7-labs-using-loopback-fast-path-with-windows-82012/

turning on the SIO_LOOPBACK_FAST_PATH option may bring a significant performance gain (when using a loopback connection, which is what I often do).

Here's a link about the background and how it is done:
https://blogs.technet.microsoft.com/wincat/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path

It looks like just one simple API call is required. Must be done both on the server and on the client side. Many users/developers may be able to add this on the client side, but it needs to be implemented on the server side. This may boost performance in some scenarios at nearly no effort!

@firebird-automations
Copy link
Collaborator Author

Modified by: @cincuranet

Link: This issue block progress on DNET726 [ DNET726 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Patch is committed into B3_0_Release branch.
Please, test it.

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Any suggestions for the best type of tests to execute to measure the performance improvement? Selects of large or small rows?

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Sean,

i think improvement should be per OS call, i.e. more calls - more profit.
I.e. case with a lot of small statements (transactions, etc) should give visible improvement.
But i can't say for sure. Ideally we should investigate all scenarions :)

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0.2 [ 10785 ]

Fix Version: 4.0 Alpha 1 [ 10731 ]

Fix Version: 2.5.7 [ 10770 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @mrotteveel

Vlad, I might be wrong, but shouldn't setFastLoopbackOption be called before initiating the listen operation (in aux_request and listener_socket)?

When running the Jaybird testsuites against 3.0.2.32664-0_x64 I don't see any noticeable difference when using -Djdk.net.useFastTcpLoopback or not.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Mark,

while developing patch i've made config setting to manage when SIO_LOOPBACK_FAST_PATH should be called - before or after listen().
That patch was tested by Karsten and he found no difference.
Also, i've tested final version of patch on WIn10 virtual machine using TPCC test and found 5-10% improvement.
Probably, you should try multythreaded test (i used 64 threads, iirc).

@firebird-automations
Copy link
Collaborator Author

Commented by: @mrotteveel

Thanks, then I'll need to see if I can find another cause for this, or if I need a different test.

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

Link: This issue relate to CORE5679 [ CORE5679 ]

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

2 participants