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

osu! diffcalc / perf deploy 2024Q4 #30

Open
16 tasks
peppy opened this issue Sep 27, 2024 · 0 comments
Open
16 tasks

osu! diffcalc / perf deploy 2024Q4 #30

peppy opened this issue Sep 27, 2024 · 0 comments

Comments

@peppy
Copy link
Sponsor Member

peppy commented Sep 27, 2024

osu! diffcalc / perf deploy 2024Q4

Published to osu! diffcalc / perf deploy 2024Q4 · Issue #30 · ppy/osu-infrastructure

community awareness

deployment scope

There has been a bit of discussion over whether we should be deploying “all” changes (including the major combo scaling change) or a limited subset. I am going with the full deployment for the following reasons:

  • I want to get the changes out as soon as possible and with minimal overhead. Running the process twice will take longer in both realtime and babysitting hours from my schedule.
  • If anything goes wrong, we will have a chance to assess and react before it impairs users’ game experience. During the reprocessing we will have things like rank history paused, so it should not have any lasting effects if we need to temporarily pause or restart the run.
  • Even if not deploying the full set of changes, it has been confirmed that virtually every osu! score’s pp value is going to change by at least 1 pp due to a slider lenience change. If this was not the case, doing a limited deploy (where we could verify that pp values didn’t change) may have had value.

preparation

  • Figure out what will still be using the old tables, and how much we need to consider them (check we're writing pp values back from the new processor at least).
  • By extension, ensure that all stable scores are given the chance to preserve in order for the highest pp score to be considered by the UserTotalPerformanceProcessor.
  • Inactive players still have non-updated pp values.
Note that these are outdated in both the old and new tables (see forum thread / Inactive users' score PP values are not reprocessed when they become active again osu#28864), peppytodo: reply in email thread when fixed
  • Ensure we have a queue setup to allow score-statistics to process stable pp values
  • Ensure stable is able to return values to the client from new pp values

pre-run

main

  • Stop osu-performance from updating pp values

iTerm2 2024-10-03 at 06 35 03

This is currently deployed and runnning on kubernetes, one instance per ruleset. Setting replicas to zero should be a safe move, and means we can rollback if required. Once we’re happy with things, removing the config.

  • Run difficulty calculation across all ranked beatmaps
osu.Server.DifficultyCalculator all -m 0 -ac -c 4 (run per ruleset)
  • Start osu-score-statistics-processor updating pp values-
Set envvar WRITE_LEGACY_SCORE_PP=1 on kubernetes
Change RunOnLegacyScores flag on performance processor
  • Merge osu!stable change to bring in diffcalc changes

post-run

future

  • Enable realtime processing for unhandled mod combinations
@peppy peppy pinned this issue Sep 27, 2024
@ppy ppy locked and limited conversation to collaborators Sep 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant