-
Notifications
You must be signed in to change notification settings - Fork 15
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
feat: add occupied slots to game rooms api (#641) #651
base: main
Are you sure you want to change the base?
Conversation
* feat: add occupied slots to game rooms api * fix: rename api parameter * fix: failing tests * chore: upgrade and remove some dependencies (#644) * chore: upgrade and remove some dependecies * feat: allow maestro to deal with multiple matches per game server (#646) * feat: allow maestro to deaul with multiple matches per game server * fix: removing cooling status * feat: add new metrics (#649) * feat: add new metrics * fix: metrics reporter tests * fix: protobuf linter offenses * fix: update buf dependencies before running linter * fix: add max validation to minFreeSlots fields
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #651 +/- ##
==========================================
- Coverage 64.30% 62.02% -2.28%
==========================================
Files 39 141 +102
Lines 2905 12111 +9206
==========================================
+ Hits 1868 7512 +5644
- Misses 909 4281 +3372
- Partials 128 318 +190 ☔ View full report in Codecov by Sentry. |
If we first divide the number of running matches per maxMatches we might end up with a number between 0 and 1, which is quirky when using math.Ceil because it would propagate the error to when computing number of desired rooms. To simplify and fix this, instead we now compute how many matches is the desired and then convert the final number to the amount of rooms/instances/pods needed to provide this number of matches: 1. How many running matches we have? * Get the value from the redis: scheduler:<scheduler_name>:occupancy 2. How many matches do we need to have based on readyTarget? * Divide running matches by 1 - readyTarget 3. How many game rooms are needed to provide this amount of matches? * Get the desired number of matches and divide by the max number of matches per room as defined in the scheduler
Some games might choose to run larger pod resources and increase number of matches running in each room/instance, thus increasing from 30 to 35. The limit in the max matches is useful so configuration stays in a sane number to help in autoscaling and roundings.
This PR implements the changes necessary for Maestro to manage multiple matches per Game Server (pod).
Motivation
Improved Server Utilization: Previously, Maestro treated Game Servers as a single unity of allocation, which was inefficient for games capable of running multiple matches concurrently, as they must implement their own logic to properly send to Maestro the Game Server state (occupied and ready).
Flexible Scaling: By introducing slot-based management, Maestro can better match server scaling to the actual workload, reducing the over-provisioning and improving cost efficiency.
Backward Compatibility: These changes ensure that existing configurations remain unaffected (e.g., default
MaxMatches=1
), allowing game teams to adopt the new functionality at their own pace.Key Changes
Scheduler Configuration
MatchAllocation
block with one parameter:New gameServer State:
Logic Updates
Active
state is managed only for Scheduler withMaxMatches > 1