Bound the matchmaking fan-out per event (#172) - #177
Open
razam-sherwani wants to merge 1 commit into
Open
Conversation
MatchmakingService builds a 4-regular graph (~2N edges) for >4 teams, so one ScheduledMatchMaker tick enqueued ~2N matches — a multi-hour backlog from a single cron tick against a small fleet. Add matchmaking.max-matches-per-event: after the edge list is shuffled, truncate it to the cap so the kept matches are a fair random sample across teams, and WARN how many were dropped. Unset / non-positive = unlimited, so deploy is a no-op until ops tunes it to fleet clearance-per-tick. Also removed a stray System.out.println in generate4RegularGraph. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Closes #172.
Problem
MatchmakingService.generateMatchesbuilds a 4-regular graph (generate4RegularGraph, ~2N edges) for >4 teams, so oneScheduledMatchMakertick enqueues ~2N matches — ~400 at 200 teams — against a small fleet. That is a multi-hour backlog from a single cron tick, and the single biggest contributor to last semester's queue.Fix
Add
matchmaking.max-matches-per-event. After the edge list is shuffled (already done for fairness), truncate it to the cap, so the matches that survive are a fair random sample across teams, andWARN-log how many were dropped for which ladder.Inert by default: unset / non-positive = unlimited, i.e. exactly today's behaviour. Deploy is a no-op until ops sets a value tuned to what the fleet can clear per tick (the server can't derive fleet size itself). Also removed a stray
System.out.printlningenerate4RegularGraph.Tests
New
MatchmakingServiceIT.createAndScheduleEventRespectsMaxMatchesPerEventCap: with the cap at 5, six teams (which would produce 12 uncapped) enqueue exactly 5. The existing 6-teams→12 test stays as the guard that the unset default is inert.Verified locally (no CI here): JDK-17 toolchain, Testcontainers Postgres+RabbitMQ. Independent of #173 and #174.
🤖 Generated with Claude Code