The problem I want to solve
Custom terrain generation can change the workload dramatically. A world that looks fine in a small test may behave very differently when players spread out, generate new chunks, or explore in several directions at once. The goal is to understand the costs before committing money to a live host.
Research areas
- Datapack compatibility with the intended Minecraft version and world-generation pipeline.
- Comparing Fabric server-side optimization options and the trade-offs versus Paper.
- Separating chunk-generation time from exploration, disk I/O, memory, and steady-state tick performance.
- Testing a small representative area locally before any large pre-generation run.
- Planning a controlled world border or staged expansion rather than generating an enormous area blindly.
How I’d test it
Start with a reproducible baseline: the exact server version, datapack version, Java version, and a clean world. Measure a small generation sample, monitor CPU/RAM/disk usage, check logs for datapack warnings, then change one variable at a time. Increase the sample size only when the numbers suggest it is sensible.
The goal is not to guess a magical maximum world size. It is to derive a practical estimate from measurements and keep an escape route if the generation cost is too high.