Key Erlang Performance Tips for Scalable Game Backend Development

Background

The author works on game backend development and examines Erlang‑specific issues and optimization points from a game‑development perspective.

1. Single‑node vs. Multi‑node

Erlang nodes communicate transparently, so many developers split subsystems (login, player, map, global, etc.) across multiple nodes to support more concurrent users. However, this introduces complex login/transition logic, frequent inter‑node broadcasts, data‑consistency challenges, higher memory usage, and operational overhead. For typical web‑games, a single node (with SMP enabled) is simpler, ensures data consistency, eases operations, and can comfortably handle up to 5,000 concurrent players, making multi‑node setups unnecessary.

2. Message Broadcasting

Broadcasting is a major performance hotspot, especially for map movement, PK actions, and world chat. While chat can be throttled via game design, movement and PK packets require low latency and must be optimized technically. Broadcast only to players within view using a 9‑grid (X,Y) lookup, avoiding full‑map broadcasts. The author’s first game stored players in a list and traversed it for each broadcast, causing high CPU usage. Switching to a 9‑grid reduced the cost dramatically. Packet caching is another useful technique.

3. Caching – Database and Network

Cache is a classic space‑for‑time trade‑off. Load essential player data into memory at server start to reduce login latency and handle concurrent logins. Frequently changing values (position, experience, gold) need not be written to the database on every change; instead, keep them in memory and persist periodically or on logout. Application‑level network packet caching (buffering packets until a size or time threshold) can also improve throughput, even though the VM and TCP already perform some buffering.

4. Process Model – How Many Processes per Player?

One Erlang process per player is sufficient. It keeps code simple, eases maintenance, and incurs minimal overhead. Spawning additional processes for networking, inventory, quests, etc., adds inter‑process communication costs and complicates the system.

5. Using the Process Dictionary

Although generally discouraged, the process dictionary offers the fastest data access in Erlang. For high‑performance game logic, it can be acceptable if access is encapsulated behind module functions (e.g., put/2 and get/1) to avoid misuse.

6. Code Conventions

Guidelines:

Keep functions simple and logical; a function should not exceed ~30 lines, a module not exceed ~1,000 lines.

Write tail‑recursive functions with clear exit conditions; ambiguous termination leads to message blocking and memory exhaustion.

Example of a safe tail‑recursive loop:

% % A clear tail‑recursive function: loop([H|T]) -> do_something, loop(T); loop([]) -> ok.

Risky version that may cause infinite loops:

% % Risky implementation: loop([H|T]) -> NewList = do_something(H, T), loop(NewList); loop([]) -> ok.

Additional recommendations:

Never trust client data; always validate uplink messages to prevent cheating.

Avoid deep nesting of case or if statements (more than three levels); prefer flat code using try…catch where appropriate.

7. Automation Tools

Automation can eliminate repetitive, patterned code (e.g., data access, protocol handling). Code generators simplify adding new protocol fields and keep client‑server contracts consistent.

8. Monitoring System

Use erlang:system_monitor/2 to watch for long garbage collections ( long_gc) and large heap usage ( large_heap).

9. Performance Analysis Tools

Prepare tools such as top memory and top message_queue to inspect system metrics on demand.