leaderboard
Cached top-N per period, refresh interval, GUI size.
leaderboard.yml controls the in-game /vote top leaderboard — how
many places to track, how often to refresh, and which periods are
exposed.
The paginated leaderboard with Total / Monthly / Weekly / Daily tabs.
Quick example
leaderboard:
enabled: true
size: 50 # how many places to cache + display
refresh-interval: 300 # seconds between background refreshes
periods:
total: true
monthly: true
weekly: true
daily: trueReference
| Key | Type | Default | Notes |
|---|---|---|---|
enabled | boolean | true | Master switch for the /vote top command and GUI. |
size | int | 50 | How many top players to cache. The GUI is paginated, so a larger number is fine. |
refresh-interval | int | 300 | Seconds between background cache refreshes. Lower = fresher, higher = less DB load. |
periods.total | boolean | true | Include the all-time tab. |
periods.monthly | boolean | true | Include the monthly tab. |
periods.weekly | boolean | true | Include the weekly tab. |
periods.daily | boolean | true | Include the daily tab. |
How the cache works
The leaderboard is not computed on every /vote top open —
that would mean a SELECT-with-ORDER-BY against the entire votes
table, every click. Instead, the plugin maintains an in-memory cache
that's refreshed in the background every refresh-interval seconds
on a single async task.
This means:
/vote topis essentially free — it's reading a sorted list already in RAM.- Top-N PlaceholderAPI placeholders (
%tdxvoteplus_top1_name%, etc.) are also lock-free reads against the same cache. - The leaderboard is up to
refresh-intervalseconds out of date. This is almost always fine; if you need it instant, droprefresh-intervalto 60 or run/voteplus refreshmanually.
On busy networks running MySQL with pool-size near its cap, a
refresh-interval of 60 will burn a connection slot every minute
per backend. The default of 300 is a good balance — most players
don't notice a 5-minute delay on a leaderboard, and you save the DB
some work.