U
/u/leaf_26
Guest
I'm just about feature complete on RTP aka LeafRTP (search engines started suppressing it because of name collision).
any rtp plugin is often the most demanding piece of software on a server and the most hidden. The heavy lifting happens inside api calls, so spark shows generic server functions instead of named plugin functions. Operators don't see it but players feel it and it affects retention.
I very much do not like a "just don't have x feature" solution.
I am a developer always trying to solve a problem. My personal specialties are in mathematics, software systems, and chaos. This is the niche I like working on as a hobby.
In 2021, I got major performance improvements by reducing api calls, via a learning algorithm, based on a modified archimedean spiral as a space filling curve and storing findings in segments.
a few weeks ago I cooked up an mca file parser for accessing unloaded data off-tick. now I can optionally bin thousands of selections by the region file their chunks fall in, so I read each region file once for a batch instead of once per teleport. that cuts way back on file operations per teleport.
now I'm pushing for stability on top of the prior latency and throughput achievements.
I'm testing now with 3 accounts (prior 2) running back to back
Paper was too close for comfort. I was only about 43% ahead.
throughput test
stability findings
I suspected that the #2 slot (ezrtp) is changing behavior based on heap limit. I went back and checked the logs and found it does modify max attempts as well as a "cache-only" mode that I'd have to investigate for a more precise description of the behavior. Accounting for heap limit is a good catch, but it still hits a failure mode occasionally under this level of pressure, that I wasn't able to induce in LeafRTP in back to back tests with the cache rate turned up.
the results appear to be consistent across the 10 or so benchmark runs I've done so far (sometimes I can't get output on huskhomes so I left that line blank for stability concerns). There were other plugins I was benchmarking here and there (advancedrtp, asyrtp, etc.) but I stopped pouring time into them due to poor performance scaling occasionally leading to timeouts during benchmarks.
folia got different results. a teleport inherently costs a region hop, but so does a chunk load. for every competitor I ran on folia (yes I tried asyrtp and advancedrtp too), I hit timeouts under load. this is likely caused by scheduler churn, preparing, ticking, and garbage collecting folia regions.
throughput test
to double check I ran again and got the same exact results (oddly specific at 7 timeouts in 600s).
stability findings
I got around the bottleneck in LeafRTP by using preexisting spatial memory, fairly new direct region file checks (assuming pregenerated world) before loading any chunk, and now also binning those checks by whichever selections land in a particular region file, to cut back on disk io
I chose to leave off sql because it's not necessarily the best tool for the job
my latest feedback (the only recent feedback) is "maybe make the plugin very easy to use even with people whos dumb and just want a plug and play gaming.", but that's not actionable feedback. idk what "plug and play" means in a general sense since every server has a different need, that's why I made the configuration prefabs.
but I'm an engineer that started minecraft in my 20s, I don't know onboarding for an average user. Best I can do is working on mapping out ease of use into a weighted matrix, using a combination of likelihood of seeing an issue and how hard issues hit.
(higher is worse)
so here's my response:
My main note here is that I want it to be easy to work with, so for the example addons I piggyback off the LeafRTP cross platform scheduler spi and networking. I want the average operator wanting a feature to look at these examples and think "I can do this"
code is updated here (including test harness) - https://github.com/DailyStruggle/RTP
I pack some docs with the plugin but also deeper docs in the wiki have been 95% updated, with room for more info as requested - https://github.com/DailyStruggle/RTP/wiki
compiled plugin here - https://modrinth.com/plugin/LeafRTP
I need more testing to hit every edge case (trying to test on every platform) but moreso I need more ux feedback.
submitted by /u/leaf_26
[link] [comments]
Continue reading...
any rtp plugin is often the most demanding piece of software on a server and the most hidden. The heavy lifting happens inside api calls, so spark shows generic server functions instead of named plugin functions. Operators don't see it but players feel it and it affects retention.
I very much do not like a "just don't have x feature" solution.
I am a developer always trying to solve a problem. My personal specialties are in mathematics, software systems, and chaos. This is the niche I like working on as a hobby.
In 2021, I got major performance improvements by reducing api calls, via a learning algorithm, based on a modified archimedean spiral as a space filling curve and storing findings in segments.
a few weeks ago I cooked up an mca file parser for accessing unloaded data off-tick. now I can optionally bin thousands of selections by the region file their chunks fall in, so I read each region file once for a batch instead of once per teleport. that cuts way back on file operations per teleport.
now I'm pushing for stability on top of the prior latency and throughput achievements.
I'm testing now with 3 accounts (prior 2) running back to back
/rtp and capturing tps, mspt, and "success" rate for "teleports within 5 seconds" on a pregenerated world (5k radius, all plugins set to 4096 blocks or 256 chunks).paper test
Paper was too close for comfort. I was only about 43% ahead.
throughput test
[th]
Plugin
[/th][th]
Att / Succ
[/th][th]
Success %
[/th][th]
TP/s
[/th][th]
p50
[/th][th]
p95
[/th][th]
p99
[/th][th]
p99.9
[/th][th]
max
[/th][th]
mean
[/th][td]
LeafRTP
[/td][td]
16560 / 16560
[/td][td]
100%
[/td][td]
18.7
[/td][td]
1 ms
[/td][td]
2 ms
[/td][td]
46 ms
[/td][td]
518 ms
[/td][td]
687 ms
[/td][td]
2.79 ms
[/td][td]
EzRTP
[/td][td]
7137 / 7018
[/td][td]
98.3%
[/td][td]
13.1
[/td][td]
30 ms
[/td][td]
189 ms
[/td][td]
322 ms
[/td][td]
1936 ms
[/td][td]
2172 ms
[/td][td]
65 ms
[/td][td]
BetterRTP
[/td][td]
1633 / 1606
[/td][td]
98.3%
[/td][td]
6.0
[/td][td]
480 ms
[/td][td]
3217 ms
[/td][td]
4402 ms
[/td][td]
6229 ms
[/td][td]
6383 ms
[/td][td]
1163 ms
[/td][td]
HuskHomes
[/td][td]
—
[/td][td]
—
[/td][td]
—
[/td][td]
—
[/td][td]
—
[/td][td]
—
[/td][td]
—
[/td][td]
—
[/td][td]
crashed server
[/td]stability findings
[th]
Plugin
[/th][th]
TPS min
[/th][th]
MSPT p99 / max
[/th][th]
Multi-second stall
[/th][th]
Server crash
[/th][td]
LeafRTP
[/td][td]
17.5
[/td][td]
85.8 / 98.4 ms
[/td][td]
none
[/td][td]
no
[/td][td]
EzRTP
[/td][td]
10.3
[/td][td]
156.8 / 292 ms
[/td][td]
p99.9 ~1.9 s tail
[/td][td]
no
[/td][td]
BetterRTP
[/td][td]
2.5
[/td][td]
859 / 3663 ms
[/td][td]
MSPT max 3.66 s; p99 4.4 s
[/td][td]
no
[/td][td]
HuskHomes
[/td][td]
—
[/td][td]
—
[/td][td]
main-thread stall
[/td][td]
crashed under same load
[/td]I suspected that the #2 slot (ezrtp) is changing behavior based on heap limit. I went back and checked the logs and found it does modify max attempts as well as a "cache-only" mode that I'd have to investigate for a more precise description of the behavior. Accounting for heap limit is a good catch, but it still hits a failure mode occasionally under this level of pressure, that I wasn't able to induce in LeafRTP in back to back tests with the cache rate turned up.
the results appear to be consistent across the 10 or so benchmark runs I've done so far (sometimes I can't get output on huskhomes so I left that line blank for stability concerns). There were other plugins I was benchmarking here and there (advancedrtp, asyrtp, etc.) but I stopped pouring time into them due to poor performance scaling occasionally leading to timeouts during benchmarks.
folia test
folia got different results. a teleport inherently costs a region hop, but so does a chunk load. for every competitor I ran on folia (yes I tried asyrtp and advancedrtp too), I hit timeouts under load. this is likely caused by scheduler churn, preparing, ticking, and garbage collecting folia regions.
throughput test
[th]
Metric
[/th][th]
LeafRTP
[/th][th]
EzRTP
[/th][td]
Attempts / Successes
[/td][td]
8786 / 8783
[/td][td]
4660 / 4638
[/td][td]
Effective success
[/td][td]
100% (3 are harness races)
[/td][td]
~99.5% nominal, but with real stalls
[/td][td]
Throughput (TP/s)
[/td][td]
14.6
[/td][td]
7.68
[/td][td]
main-thread CPU / attempt
[/td][td]
2.87 ms
[/td][td]
6.26 ms
[/td][td]
MSPT avg / p95 / max
[/td][td]
50.2 / 51.0 / 341 ms
[/td][td]
50.8 / 51.0 / 307 ms
[/td][td]
Latency p50 / p95 / p99
[/td][td]
100 / 150 / 183 ms
[/td][td]
225 / 494 / 704 ms
[/td][td]
Latency p99.9 / max
[/td][td]
268 / 501 ms
[/td][td]
1399 / 4598 ms
[/td][td]
TIMEOUTs
[/td][td]
3 (attribution races)
[/td][td]
22 (real, batched with freezes)
[/td][td]
Folia region freezes
[/td][td]
0
[/td][td]
7 (one region 21.0 s)
[/td]to double check I ran again and got the same exact results (oddly specific at 7 timeouts in 600s).
stability findings
[th]
Metric
[/th][th][/th]
Test-run-A[th][/th]
Test-run-B[td]
EzRTP region freezes
[/td][td]
7
[/td][td]
7
[/td][td]
Worst freeze
[/td][td]
21.0 s
[/td][td]
20.4 s
[/td][td]
RTP region freezes
[/td][td]
0
[/td][td]
0
[/td][td]
EzRTP / RTP TIMEOUTs
[/td][td]
22 / 3
[/td][td]
122 / 4
[/td]How
I got around the bottleneck in LeafRTP by using preexisting spatial memory, fairly new direct region file checks (assuming pregenerated world) before loading any chunk, and now also binning those checks by whichever selections land in a particular region file, to cut back on disk io
I chose to leave off sql because it's not necessarily the best tool for the job
my latest feedback (the only recent feedback) is "maybe make the plugin very easy to use even with people whos dumb and just want a plug and play gaming.", but that's not actionable feedback. idk what "plug and play" means in a general sense since every server has a different need, that's why I made the configuration prefabs.
but I'm an engineer that started minecraft in my 20s, I don't know onboarding for an average user. Best I can do is working on mapping out ease of use into a weighted matrix, using a combination of likelihood of seeing an issue and how hard issues hit.
| Factor | Weight | LeafRTP | BetterRTP | EzRTP |
|---|---|---|---|---|
| Onboarding: get desired behavior quickly | 0.30 | 0.90 | 0.30 | 0.60 |
| Config simplicity for common tasks | 0.20 | 0.60 | 0.20 | 0.40 |
| Out-of-box default quality | 0.15 | 0.15 | 0.15 | 0.15 |
| Perceived value during evaluation | 0.10 | 0.20 | 0.10 | 0.10 |
| Runtime stability at scale | 0.10 | 0.00 | 0.20 | 0.20 |
| Self-serve support when stuck | 0.10 | 0.10 | 0.10 | 0.10 |
| Platform fit | 0.05 | 0.00 | 0.10 | 0.05 |
| Churn-risk total | 1.95 | 1.15 | 1.60 |
(higher is worse)
so here's my response:
- book-based
rtp menuandrtp adminpanels - config editor with search tool
- prefabs in the admin panel (I need feedback from users for settings)
- map based region visualizations and mspt+heap sparkline
- drop-in network integration
- schematic-based platform creation support (with skyblock example)
- pvp checks (with or without other plugins)
- an api hook for menu integration on the
/rtpcommand and a demo menu - bossbar "countdown" example addon
- mirrored betterrtp's "limits" config
My main note here is that I want it to be easy to work with, so for the example addons I piggyback off the LeafRTP cross platform scheduler spi and networking. I want the average operator wanting a feature to look at these examples and think "I can do this"
code is updated here (including test harness) - https://github.com/DailyStruggle/RTP
I pack some docs with the plugin but also deeper docs in the wiki have been 95% updated, with room for more info as requested - https://github.com/DailyStruggle/RTP/wiki
compiled plugin here - https://modrinth.com/plugin/LeafRTP
I need more testing to hit every edge case (trying to test on every platform) but moreso I need more ux feedback.
submitted by /u/leaf_26
[link] [comments]
Continue reading...