การทดสอบภาระงานของระบบเรียลไทม์

A REST endpoint can be load tested with simple request bursts. Real-time systems hold thousands of long-lived connections, each pushing and pulling continuously.

Load testing must model that sustained, stateful traffic, not just request counts.

• Concurrent connections the system holds.
• Messages per second in and out.
• End-to-end latency under load.
• Resource use: CPU, memory, file descriptors.

Test not only steady state but the ramp: what happens when 10,000 clients reconnect at once after a deploy or network blip? This thundering herd often breaks systems that handle steady load fine.

Use tools built for persistent connections such as k6, Artillery, or Gatling. They open many sockets and script message flows.

Here is a minimal k6 scenario that opens a socket, sends a message, and listens for replies.

WebRTC is heavier: each virtual user needs a peer connection and media. Tools like KITE or headless browser farms simulate real media flows, while SFU-level harnesses inject synthetic RTP to stress forwarding.

One machine cannot open hundreds of thousands of sockets. Run load generators across many nodes so the generator is not the bottleneck. Aggregate their metrics centrally.

Each connection consumes a file descriptor. Raise ulimit -n and tune ephemeral port ranges on both the server and load generators, or you will hit artificial ceilings.

Set explicit SLOs so a test objectively passes or fails, for example p95 latency under 200ms and zero dropped connections up to 50k clients.

Ramp connections steadily and watch where latency or errors spike, the knee of the curve. That number is your safe capacity per node and drives autoscaling thresholds.

Run against the same instance sizes, load balancer, and TURN setup as production. A test on a laptop tells you little about cloud behavior under real network egress limits.

Load test real-time systems by simulating sustained concurrent connections and reconnect storms with tools like k6 or Artillery, distributing generators, tuning OS limits, and ramping until you find the capacity knee against production-like infrastructure.