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

DNS round-robin ignored, always uses the same host #738

Closed
stephank opened this issue Aug 10, 2018 · 8 comments
Closed

DNS round-robin ignored, always uses the same host #738

stephank opened this issue Aug 10, 2018 · 8 comments

Comments

@stephank
Copy link

stephank commented Aug 10, 2018

k6 calls FetchOne on the DNS resolver:

https://github.com/loadimpact/k6/blob/d4152d20221c0c466c93fe5cabb8e8f8c885cb5b/lib/netext/dialer.go#L67

But this only ever returns the first entry from the cache:

https://github.com/viki-org/dnscache/blob/c70c1f23c5d84ab39054ec6b418a5ed0fa51cade/dnscache.go#L37

Our HAProxy frontends individually limit requests, and our load test was exceeding those limits, while the entire HAProxy cluster should've been able to handle the load. The error message k6 logged showed it was using the same host for all requests. (Or at least, the failing requests.)

As test and temporary workaround, I've adjusted our script to list the IPs and pick one at random for each VU, and the load test is now fine. (For this, we had to use --insecure-skip-tls-verify. This'd also break vhosts, but that wasn't a problem for us. And maybe that can also be worked around by setting Host manually.)

@na--
Copy link
Member

na-- commented Aug 13, 2018

This is very loosely connected to #726 and it may be worth it to fix both at the same time

@ofauchon
Copy link
Contributor

Hi,

How would you like these issues to be solved (#726 / #738) ?
I can see multiple solutions:

  • Propose patches for inclusion in github.com/viki-org/dnscache
  • Fork github.com/viki-org/dnscache in loadimpact repositories
  • Write a new, k6-specific DNS resolver for the project

Thanks;
Olivier.

@na--
Copy link
Member

na-- commented Aug 20, 2018

I'm not sure what the best solution would be, sorry. I'd start by investigating whether we need dnscache at all, since it would be better if the OS or the go standard library handled DNS caching in a manner that complied with TTL and could handle multiple IPs per domain.

Regarding github.com/viki-org/dnscache - it seems like it's a very small library that hasn't been updated in over 5 years, so if we have to use some form of dns caching, we should probably replace it with a more fully-featured library (if such a thing exists) or write one ourselves.

@na--
Copy link
Member

na-- commented Aug 27, 2019

This, together with #726 will be fixed once we switch to the new caching DNS resolver that @bookmoons is currently woking on (https://github.com/bookmoons/resolvent/)

@na-- na-- modified the milestones: v0.26.0, v0.27.0 Oct 10, 2019
@na-- na-- modified the milestones: v0.27.0, v0.28.0 May 21, 2020
@mstoykov mstoykov modified the milestones: v0.28.0, v0.29.0 Sep 22, 2020
@brandonh-msft
Copy link

any update on this?

@na--
Copy link
Member

na-- commented Oct 7, 2020

@brandonh-msft, yes, actually! It was fixed in #1612, which was almost released as a part of k6 v0.28.0. Unfortunately we didn't merge it because of some last-minute IPv6 issues we found, so it's going to be released as a part of k6 v0.29.0, slated for release mid-November.

It's likely there would also be further DNS improvements in k6 as well (#1637), though (somewhat ironically judging by your user name), from what I understand, there are some issues with that PR on Windows, so it might be delayed until v0.30.0 or maybe only work on Linux and Mac. In any case, the round-robin fixes will be available soon in v0.29.0, and even sooner in master.

@brandonh-msft
Copy link

brandonh-msft commented Oct 13, 2020

@brandonh-msft, yes, actually! It was fixed in #1612, which was almost released as a part of k6 v0.28.0. Unfortunately we didn't merge it because of some last-minute IPv6 issues we found, so it's going to be released as a part of k6 v0.29.0, slated for release mid-November.

k - we don't want to wait until then so we'll look at building/pulling the branch in which it was fixed

It's likely there would also be further DNS improvements in k6 as well (#1637), though (somewhat ironically judging by your user name), from what I understand, there are some issues with that PR on Windows, so it might be delayed until v0.30.0 or maybe only work on Linux and Mac. In any case, the round-robin fixes will be available soon in v0.29.0, and even sooner in master.

We're not using the client on Windows so 0.29.0 will be fine

cc @priyaananthasankar

@na--
Copy link
Member

na-- commented Oct 20, 2020

Closed by #1612

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

5 participants