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

Somehow, there is an exact 2s delay from nameserver resolution to connection setup #78

Open
buehler opened this issue Mar 8, 2022 · 4 comments
Labels
bug Something isn't working status:blocked Work on this feature is blocked due to external dependencies

Comments

@buehler
Copy link

buehler commented Mar 8, 2022

Describe the bug
I've been experimenting with a local grpc server when I saw that each call needs exactly around 2 seconds.
Between "resolution stop" and "connection established" there is a 2s delay for no reason. When I tried the same call in Insomnia gRPC, it was nearly instant.

To Reproduce
Steps to reproduce the behavior:

  1. Have a grpc server
  2. Create a call
  3. Send call :)

Expected behavior
That it should be blazingly fast

Screenshots
image

Environment (if possible, copy the information from the error dialog or the About menu):

  • OS: Win 11
  • Kreya Version: 1.7.0 Stable
@buehler buehler added the bug Something isn't working label Mar 8, 2022
@buehler
Copy link
Author

buehler commented Mar 8, 2022

{
"kreyaVersion": "1.7.0",
"platform": "Win32",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36 Edg/99.0.1150.30"
}

@CommonGuy
Copy link
Contributor

I cannot reproduce this:
grafik

Could you try calling your API via http://127.0.0.1:8080 and http://[::1]:8080? I suspect IPv6 issues when resolving localhost, where Kreya tries to connect to the "IPv6 IP", but has to fall back to the "IPv4 IP".

@CommonGuy CommonGuy added the status:needs-info To investigate this, more information is needed label Mar 8, 2022
@buehler
Copy link
Author

buehler commented Mar 10, 2022

Huhu :)

Yep, when I use 127.0.0.1 it is blazingly fast.

@CommonGuy
Copy link
Contributor

Ok, then that's the workaround for now...

As for improving this, we are blocked until dotnet/runtime#26177 has been implemented into the .NET "gRPC infrastructure" (mainly HttpClient/SocketsHttpHandler).

@CommonGuy CommonGuy added status:blocked Work on this feature is blocked due to external dependencies and removed status:needs-info To investigate this, more information is needed labels Mar 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working status:blocked Work on this feature is blocked due to external dependencies
Projects
None yet
Development

No branches or pull requests

2 participants