Question
Latency spikes in Photon Realtime OpCreateRoom/OpJoinRoom under concurrent requests
Kavi Indigo
0 reputation · 02 Aug 2023, 07:06 UTC
72K views
Loading…
0 reputation · 02 Aug 2023, 07:06 UTC
Determine whether enabling Photon’s Async HTTP fallback or adjusting the server’s MaxCCU setting deterministically reduces the latency spikes observed when many clients issue OpCreateRoom or OpJoinRoom operations concurrently.
Photon Realtime queues these operations on the game server’s per‑peer message dispatch queue, and the latency increase depends on an unspecified concurrency threshold; while the documentation mentions Async HTTP and MaxCCU, it does not expose the internal throttling algorithm that would guarantee a predictable effect on queuing delay.
Does enabling Async HTTP fallback change the observed latency pattern under a fixed concurrent load? Does raising the MaxCCU limit produce a proportional reduction in queuing delay? Is there a measurable concurrent‑request threshold beyond which latency spikes persist regardless of these settings?
35275 reputation · 02 Aug 2023, 17:03 UTC
Enabling Photon’s Async HTTP fallback does not change the latency pattern for OpCreateRoom or OpJoinRoom when many clients issue requests concurrently. Raising the MaxCCU setting can reduce spikes only if the current value is below the number of active connections, but it does not guarantee a proportional decrease because the real bottleneck is the server’s thread‑pool and the MaxConcurrentCreateRoom limit. There is a practical threshold—roughly the size of the thread pool or the configured MaxConcurrentCreateRoom value—beyond which latency spikes persist regardless of these settings.
photonengineOpCreateRoom or OpJoinRoom requests exceeds the pool size, excess requests are queued, causing back‑pressure and increased latency.MaxConcurrentCreateRoom (default 50) per server instance. If this limit is hit, the server logs warnings and queues additional create requests, adding to response time.MaxPlayers limit, the server performs a full membership check and locks the room data structure, which can produce spikes in join latency.OpCreateRoom or OpJoinRoom traffic.MaxCCU allows more concurrent connections, but if the thread pool or MaxConcurrentCreateRoom limit is the bottleneck, latency spikes will not disappear.DebugLevel = 3) and monitor the ThreadPool metrics to see if requests are being queued.MaxConcurrentCreateRoom value (default 50) and the size of the server’s thread pool in the configuration or admin console.MaxConcurrentCreateRoom threshold, raise that value in the server config and repeat the test.MaxCCU is set high enough to accommodate all active connections; if it is lower, raise it and observe whether the spikes diminish.To fine‑tune the recommendation, could you provide the current MaxConcurrentCreateRoom setting and the thread‑pool size on your Photon server?
Use comments to ask for clarification. Post a solution as an answer.
6,610 reputation · 02 Aug 2023, 11:00 UTC
Assuming a recent Photon Realtime version, a useful distinction for this discussion: MaxCCU controls connection admission, not operation throughput. Raising it only helps when active peers are being rejected; it does not reduce queuing delay for OpCreateRoom or OpJoinRoom once connections are established.
Concurrent room operations also contend for the room registry and membership state, introducing synchronization overhead independent of the thread pool. Because Photon does not document its internal throttling algorithm, the exact concurrency threshold where spikes persist should be treated as an empirical measurement rather than a deterministic setting.
To verify, run a controlled load test with MaxCCU set well above the active peer count and compare operation RTT. If spikes remain, the bottleneck is operation-level queuing or lock contention, not connection limits. Architectural changes—such as distributing rooms across server instances—may offer more predictable relief than adjusting MaxCCU.