Randomize --connect-to if multiple matching options #695
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here is a PR to better handle this:
In this case, a random choice will be made for each request between
backend1.fqdn:8443
andbackend2.fqdn:8443
. Where as currently, while the syntax is not rejected, it's always the same target which would be picked.My use case is being able to bypass an actual TCP load-balancer in front of the backend servers, just to check it doesn't have a significant impact on the overall performances.
I've seen that DNS resolution already makes some similar random choice per-request in case several IP are returned for the domain. I guess I could use that (with some local dnsmasq entries) for my use case, but this
--connect-to
approach sounds more intuitive.The second commit is a test case with 100 requests to spread across two servers, listening on two local ports. It checks that both receive at least some requests, and that the total number of requests received is indeed 100.