Fix delay in creating redis connections #35
Merged
+3
−2
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.
So... I'm going to preface by saying that I've gone deep but haven't gone through the full length necessary to determine what/when/how things went wrong here.
When running osu-queue-score-statistics tests, I found them getting slower over time and the cause to be Redis. You can attach a log to the Redis configuration options to get a bit more info, here's an excerpt:
Note that the entire 1s connection time was taken up between the two lines:
What's going on here? https://github.com/StackExchange/StackExchange.Redis/blob/c8a7265d475c24834ed3497140cdf98bbfd50975/src/StackExchange.Redis/ServerEndPoint.cs#L924-L1009
It looks like not much at all! We get a few variables from the options, call
SetProtocol
which is really just a property setter, and then print the client name.An important note to understand here is that
ConnectionMultiplexer
offloads the connection to a separate thread and then effectively calls.Wait()
waiting for that thread. That is to say, the call/profile stack isn't immediately obvious. Until you look at that background thread and find:This background thread is wasting all of its time in some
TryGetAzureRoleInstanceIdNoThrow
method which just returnsnull
.This is where my investigation stops. For some reason
Type.GetType()
is getting slower over time - this could be because of how the XUnit test runner works internally, perhaps it's creating assemblies/types and the list is growing over time to a point it eventually becomes unmanageable.I've gone with the most simple solution here which is to cache the config options, with the hope that this is self-explanatory/acceptable enough on its own to not have to document the insanity involved.