Modpack Server Capacity: What to Test Before Opening
To size a modpack server, test the intended release with a representative world, players performing defined activities and repeated measurements. Joining an empty spawn only proves that a connection works. It does not establish how the server behaves once developed bases, machines and exploration run together.
For an established community, the useful decision is which workload has been checked and under what conditions you can open. This procedure helps you commission that work and assess the handover. It is a proposed test plan: we have not run a server or measured capacity for this article. There is no universal conversion from gigabytes or mod count to player capacity.
Specify the workload before requesting resources
Record the exact modpack, Minecraft, loader and Java versions, configuration and world state. Include the test machine, resource limits and any services sharing it. If the production environment will differ, keep that difference visible in the conclusion.
Set a concurrent player target rather than using your total Discord membership. Describe what those people will do: gather together, work in separate bases, travel between dimensions or explore new terrain. A connection count cannot replace that description.
The modpack release handover checklist covers installation and compatibility. Complete that work before measuring performance. A session where participants cannot join because their releases differ does not represent the intended workload.
Ask the pack maintainer to identify builds and mechanics representative of a developed season. If you only have a new world, construct a synthetic scenario and state its limitations. Do not describe it as evidence from a mature community.
Start from an isolated, repeatable copy
Use a recoverable world copy and separate external integrations so the rehearsal cannot change live data. Preserve an identifiable starting point for repeated runs. A backup restore rehearsal helps establish that starting point.
Hold constant the variables you are not investigating. Changing memory, distances, mods and world state between sessions prevents you from attributing an improvement to one cause. Store configuration differences with the results.
Separate startup and warm-up from sustained measurement. Then run a phase long enough to observe relevant cycles: machines, saves and periodic jobs that will actually operate during play. There is no universal minimum duration. If a scheduled job never runs, record that it was outside the test coverage.
Exercise four different workloads
This matrix is a proposed procedure, not a benchmark or guarantee. Keep the same target concurrency across scenarios so you can investigate differences caused by activity.
| Scenario | Activity to prepare | What it investigates |
|---|---|---|
| Opening gathering | Participants together in the arrival area | Behaviour during the expected concentration of players. |
| Developed bases | Groups at several bases with machines running | Sustained work from the pack's mechanics. |
| Exploration | An agreed route through new terrain and relevant dimensions | The difference between settled play and terrain generation. |
| Mixed session | Active bases, travel and expected periodic jobs | Workloads that will overlap in production. |
Describe actions precisely: which machine starts, which recipe it processes and which route players follow. “Play normally” is hard to repeat. For exploration, identify whether terrain already existed. Repeating a route after generating it changes the test.
If you cannot gather the required participants, limit the conclusion to the group tested. Idle clients and partial simulations can investigate individual components, but they do not automatically validate the experience of the complete modpack.
Record tick times and their context
Use a spark build compatible with your server and loader, following the installation documentation. Check the selected download's compatibility. A Paper plugin is not interchangeable with a server mod simply because both carry the same project name.
TPS describes tick frequency; MSPT describes time spent processing ticks. At 20 TPS, the average budget is 50 milliseconds per tick. Examine variation too: spark provides median and 95th-percentile values as well as extremes. A comfortable average can hide noticeable pauses. The official TPS and MSPT guide explains the relationship.
For each phase, record time, active participants, actions, TPS, available tick-time distribution, memory and observations. The spark command reference documents /spark tps, /spark health show --memory and /spark gc. Preserve measurement windows: an instantaneous snapshot and an entire session are not equivalent comparisons.
When a problem appears, add a profile captured during the scenario that reproduces it. A large percentage in a profile guides investigation; it does not by itself prove that a mod is defective. Connect the capture to the actions and logs from that run.
Agree release criteria before interpreting results
Before testing, agree which behaviour blocks opening: unexpected shutdowns, persistent errors, essential actions that stop responding or sustained degradation of game speed. Also define how you will assess brief pauses and what headroom you want to retain. The 50 ms budget explains tick timing; it is not a complete user-experience contract.
Consider a decision example without invented measurements. If the developed-base phase passes but exploration fails your agreed criterion, do not approve the entire workload. Investigate that scenario, change one variable and repeat it. If you restrict exploration for opening, document the restriction and confirm that the planned game format allows it.
A high memory reading alone does not establish a leak. Adding memory does not demonstrate that the cause of pauses has been fixed. Review trends, garbage-collection activity and the profile before choosing the next change. Repeat affected phases with the configuration you will actually deliver.
Do not replace a failed result with the best run and discard the others. Keep the sequence, explain deliberate changes and mark interrupted sessions. If results vary substantially without an identified change, investigate that uncertainty before drawing a firm capacity conclusion.
Require a handover that another operator can use
Request the version and environment record, starting world state, activity scripts, phase logs and issue list. Each case should be marked executed, failed or pending, with evidence and an owner for the next step. A screenshot showing 20 TPS does not replace that record.
The conclusion should name the tested workload and its limits: concurrency, activities, duration and differences from production. Pack changes, additional machinery or changes to loading rules require a decision about retesting. The result describes specific conditions; it does not certify unlimited future growth.
For managed infrastructure for your community, bring this brief and your opening date. Mineando scopes paid projects individually. Agree the environment, scenarios and evidence required at handover before the rehearsal. Ongoing maintenance and live coverage are agreed separately.
