MMO Server Concurrency Limits

Understanding the Question
You’re essentially asking: “In a modern ‘massively-multiplayer, open-world’ MMO, how many concurrent players can a single physical (or cloud) server realistically handle before it hits a bottleneck? And which tends to be the bottleneck first—CPU or network?”

Below is a consolidation of publicly known or commonly cited figures and considerations from game developers’ experiences over the years. Keep in mind that exact numbers vary widely depending on game design, engine optimization, and hardware setups.

---

Typical Concurrency per Single “Shard” (Single Server)

1. A Few Hundred to a Few Thousand Concurrents

   • For most large-scale MMO architectures, a single “world shard” is actually a cluster of multiple servers or virtual machines working together. However, if we talk about one machine (one server instance) within that cluster handling one region or zone, often the concurrency limit is measured in the low thousands or sometimes just hundreds.
   • Historically, many traditional MMORPGs (e.g., older World of Warcraft realms, early Guild Wars areas) aimed to keep zones or “nodes” in the low-to-mid thousands of concurrently connected players. Beyond that, performance and gameplay experience could degrade significantly.

2. Examples/Estimates

   • World of Warcraft: Blizzard never disclosed exact per-instance server hardware concurrency. However, community estimates suggest that a single WoW “realm” back in the day was typically handled by multiple machines. Each “world zone” or “instance server” might have been configured for a few thousand concurrent players before layering/sharding is triggered.
   • EVE Online: Famous for its single-shard universe, but each star system runs on a separate node in a large cluster. In huge battles, CCP moves the heavily populated system to stronger hardware, sometimes still capping out around a few thousand players in a single system (node). Beyond that, they employ “time dilation” to avoid meltdown. So you might say one node can handle a couple thousand concurrently before performance becomes an issue.
   • ArcheAge, Final Fantasy XIV, Elder Scrolls Online: All use world “sharding” or “channeling.” A single shard often still runs as multiple processes on multiple servers, with each zone or instance assigned. In general, single-zone concurrency in the low-thousands is common.
   • Planetside 2: Not a classic fantasy MMO, but often cited for large battles on a single contiguous map. Officially, battles can climb toward 2,000 players in one area. Again, that is spread over multiple processes/nodes but is described to players as “one continuous area.”

Bottom Line on Scale

If you truly pin it down to a single standalone server instance (whether a dedicated bare-metal box or a single cloud VM), most real-world MMO deployments are sized to handle from a few hundred up to a few thousand concurrent players comfortably.

---

Packet Rates & Bottlenecks

1. Packet Rate (30 PPS)

• You mentioned 30 pps (packets per second) per client. That’s a decent ballpark for many MMOs, though it can go higher or lower depending on netcode.
• If you had, say, 2,000 concurrent clients, each sending ~30 packets per second, that’s ~60,000 inbound packets per second. Outbound is of similar or higher magnitude, though it’s often aggregated or interest-managed so not every outgoing packet goes to every player.

2. Network Bandwidth vs. CPU

• Network Bandwidth: At thousands of clients with 30 pps, the total bandwidth (in Mbps or Gbps) can be significant but is often still less likely to be the very first bottleneck if you have a good data center connection (1 Gbps or 10 Gbps).
• CPU/Compute: Handling game logic, interest management (deciding who sees what), collision checks, AI, and other server-side computations typically become the bigger constraint. Each incoming packet triggers a server update (movement, skill usage, physics check, replication to other clients, etc.). The complexity of that logic can easily saturate CPU cores long before saturating a 1 Gbps line.
• Memory can also be a limiting factor if the server needs to maintain large world-state databases, but modern servers typically scale memory up more easily than CPU.

In practice, CPU (and sometimes the overhead of the game engine’s architecture) is usually the first brick wall. Networking load is substantial, but well-optimized netcode and a decent data center connection often keep raw bandwidth from being the #1 bottleneck.

---

Key Points in Production Environments

1. Sharding / Instancing

   • Most MMOs split the world into zones or “shards” to avoid letting concurrency in any one process climb too high.
   • When a zone starts filling up (e.g., 1,500–2,000 players in some games), new players might be placed in a new instance or “layer.”

2. Server “Scaling Up”

   • Modern architectures often rely on scaling out horizontally rather than pushing a single server to monstrous concurrency. This keeps performance more stable, especially during peak hours or big events (like raids or massive PvP battles).

3. Engineering Trade-Offs

   • Some engines push updates less frequently or rely on interest management (only send relevant updates to nearby players). These strategies are crucial to keep concurrency higher.

---

Conclusion and Approximate Figures

1. Single Commodity Server: Handling hundreds to low-thousands of concurrent players is a common practical upper range for an open-world MMO process, given 30 pps netcode and typical CPU constraints.
2. Bottleneck: Usually CPU and logic handling (interest management, game mechanics) is the first major bottleneck. Network bandwidth certainly matters but is often more scalable.
3. Real MMO Deployments: Use clusters. Even if the marketing says “one shard,” it’s typically many physical or virtual servers behind the scenes. EVE Online, for example, famously lumps everyone into “one universe” but behind the curtain it’s a dynamic cluster with each star system spinning up on different hardware.

Hence, while you might see mention of a “10,000-player server” in marketing or in certain special “single-shard” designs, each “server” is typically a cluster, and each node (one actual machine/VM) is dealing with a fraction of that concurrency. Real-world stable concurrency for one server instance is most often on the order of a few thousand at best—and that’s assuming a well-optimized, AAA-level backend and substantial hardware resources.