Scaling vertically vs. horizontally: how to grow your MU Online server
Understand when to scale your MU Online server vertically (more resources on one machine) or horizontally (more machines/instances), with decision criteria, costs, risks, and a practical migration plan as your player base grows.
Every growing MU Online server faces the same question: when to stop simply "throwing more hardware" at the same machine and start distributing the load across several? Scaling vertically (more CPU, RAM, and disk on a single machine) and scaling horizontally (more machines or instances splitting the
Every growing MU Online server faces the same question: when to stop simply "throwing more hardware" at the same machine and start distributing the load across several? Scaling vertically (more CPU, RAM, and disk on a single machine) and scaling horizontally (more machines or instances splitting the work) solve different problems, cost differently, and carry different risks. Deciding wrong — whether scaling horizontally too early or insisting on vertical past the point of return — wastes budget and still leaves the server slow. This tutorial explains both paths, how to diagnose which bottleneck you actually have, and how to plan the transition without breaking the server in production.
What vertical scaling is
Scaling vertically means increasing the capacity of the same machine: more CPU cores, more RAM, faster disk (NVMe SSD instead of SATA), or a larger cloud instance tier. For a typical MU Online server (ConnectServer, GameServer, database, all or part on the same machine), this is the first and simplest growth path, and it solves most bottlenecks well up to a few hundred concurrent players.
What horizontal scaling is
Scaling horizontally means splitting the load across multiple machines or instances: an additional GameServer for another channel/sub-server, a replicated database, or even auxiliary services (website, launcher, payment system) running off the main game machine. It's more complex to set up and maintain, but it removes the physical ceiling of a single machine and improves resilience — if one instance goes down, the others stay up.
Diagnosing the bottleneck before deciding
Before choosing a direction, identify where the problem is:
| Observed symptom | Likely bottleneck | Indicated direction |
|---|---|---|
| General lag at peak hours, machine CPU at 90%+ | Insufficient processing power (CPU) | Vertical (more/faster CPU cores) |
| Freezes when many players log in simultaneously | Database under contention | Vertical (SSD, more RAM for cache) or horizontal (read replica) |
| Slowness only in a specific crowded map/event | Too many players/monsters in the same map instance | Horizontal (more channels/sub-servers) |
| Website/shop slow but the game itself is normal | Web service competing for resources with the game | Horizontal (separate the site from the game server) |
| Constant RAM usage, no CPU spike, but still freezing | Insufficient memory for the player volume | Vertical (more RAM) |
Running monitoring tools (CPU, RAM, disk I/O, and network latency usage) for at least a week, covering peak hours and events, is what separates an informed decision from an expensive guess.
Comparing costs: vertical vs. horizontal
| Criterion | Vertical | Horizontal |
|---|---|---|
| Initial cost | Lower (one bigger machine) | Higher (multiple machines/instances) |
| Setup complexity | Low to medium | Medium to high (load balancing, synchronization) |
| Growth ceiling | Limited by maximum available hardware | Practically unlimited (add more nodes) |
| Failure resilience | Low (single point of failure) | High (other instances stay up) |
| Implementation time | Fast (plan/hardware upgrade) | Slower (requires architecture and testing) |
For most growing MU servers (tens to a few hundred concurrent players), vertical still delivers the best cost-benefit. Horizontal becomes necessary once the server is large enough to justify the extra complexity.
Separating services before separating machines
An intermediate step, often overlooked, is to separate services logically before separating them physically: run ConnectServer, GameServer, database, and website in distinct processes or containers, even if still on the same machine. This makes a future horizontal migration much easier, because each service is already isolated and can be moved to another machine without rewriting configuration from scratch.
Scaling the database
The database is often the most subtle bottleneck, because a machine can "look" like it has plenty of CPU and RAM to spare while the database suffers from locks and slow queries. Before scaling horizontally with replicas, exhaust the cheaper vertical optimizations: proper indexes on character/inventory tables, database memory cache tuning, and dedicated SSD storage for data files. Only after that should you consider read replicas or sharding.
Scaling the GameServer with multiple channels
The most common form of horizontal scaling in MU is adding extra sub-servers/channels in the same world, each running its own GameServer instance connected to the same ConnectServer and database. This spreads out the player population without duplicating characters or the economy, but it requires the ConnectServer and connection balancing to be well configured to distribute players evenly across channels.
Migration plan without extended downtime
- Implement monitoring before any migration, to have a baseline for comparison.
- Separate services logically (distinct processes) before separating them physically.
- Scale vertically the most critical service (usually the database) until its cost-benefit is exhausted.
- When you decide on horizontal, start with the easiest service to isolate (website/shop), not the game's core.
- Add an extra channel/sub-server during low-traffic hours and monitor closely for the first 48 hours.
- Only after that consider database replication or more sophisticated load balancing.
When NOT to scale (the problem is something else)
Many "capacity problems" are actually configuration problems: queries without indexes, poorly optimized events running unnecessary calculations every tick, or excessive logging writing to slow disk. Scaling (in either direction) without fixing these issues only postpones the symptom and increases cost — always rule out configuration causes before investing in more hardware.
Common errors and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Scaled vertically and nothing improved | The real bottleneck was configuration/queries, not hardware | Review indexes, queries, and configuration before scaling again |
| Scaled horizontally and got slower | Poorly configured synchronization between instances | Review the communication architecture between GameServers/database |
| Infrastructure cost spiked with no player growth | Scaled too early, without prior diagnosis | Go back to monitoring and size based on real usage |
| Players unevenly distributed across channels | Poorly configured connection balancing | Adjust the distribution logic in the ConnectServer |
| One instance failing takes down the whole game | Architecture still monolithic despite "looking" scaled | Separate services logically before relying on horizontal resilience |
Scaling checklist
- CPU, RAM, disk, and network monitoring implemented for at least one week.
- Real bottleneck identified (CPU, database, crowded map, or web service).
- Configuration/query optimizations applied before scaling hardware.
- Services separated logically (distinct processes/containers).
- Vertical vs. horizontal decision made based on data, not guesswork.
- Migration tested during low-traffic hours before rolling it out to everyone.
- Rollback plan defined in case the migration causes instability.
Once your scaling strategy is set, it's also worth reviewing the network layer that delivers this extra capacity to players — read the tutorial on choosing a datacenter for low latency to make sure your infrastructure investment actually translates into a better experience for the end player.
Frequently asked questions
Which should I scale first: vertical or horizontal?
Almost always vertical first. It's simpler, cheaper upfront, and solves most of the bottlenecks in a small-to-medium MU server (a few hundred concurrent players). Move to horizontal only when vertical hits its cost-benefit ceiling or a physical hardware limit.
Does MU Online support multiple GameServers for the same world?
Most modern emulators support multiple GameServers connected to the same ConnectServer and database, splitting players between them (sometimes by sub-server/channel). This is the foundation of horizontal scaling, but it requires attention to data synchronization and latency between services.
Is horizontal scaling more expensive than vertical?
In the short term, generally yes — multiple machines cost more than a single bigger machine. In the long term, for a large player base, horizontal tends to be cheaper and more resilient, since it avoids paying for top-tier hardware at a disproportionate cost for the gain.
What happens if I scale in the wrong direction (horizontal too early)?
You pay the cost of added complexity (synchronization between servers, load balancing, more points of failure) without the benefit, because the real problem was still query or configuration optimization, not a lack of raw capacity. Diagnose the bottleneck before choosing a direction.
How do I know I've hit the ceiling of vertical scaling?
When doubling the machine's CPU/RAM no longer reduces latency or freezes, and the bottleneck shifts to network, shared disk I/O, or database concurrency that a single machine can't solve — that's the signal to move to horizontal.