One webrtc.NewAPI() per SDP offer is a load-bearing bug, and thirty viewers will find it

A post on dev.to describes a failure mode that anyone who has shipped Pion will recognise: follow the usual Go guides, deploy a WHEP handler, open a handful of player tabs, and the server starts choking ^[1]. Handshakes stretch to seconds, ICE times out, and half the pprof flame graph is `crypto/elliptic.p256OrdSqr` plus map allocations inside the engine ^[2].

The pattern under all of it is the one printed in most tutorials: for every POST carrying an SDP offer, construct a new `webrtc.NewAPI()`, register the default codecs, call `api.NewPeerConnection()`, return the answer ^[3]. On localhost with two clients it flies; in production it does not ^[4]. The author's read is blunt: many of these guides look like they were never load-tested with even fifty concurrent viewers ^[5]. The diagnosis is not that WebRTC, Pion or Go is slow, but that expensive global infrastructure is being built per request instead of reused ^[6].

Three costs are being paid on the request path, and none of them belong there. First, DTLS needs a certificate, which means generating ECDSA P-256 keys through `crypto/ecdsa`, elliptic-curve arithmetic and `crypto/rand` ^[7]. Second, the engine allocates hundreds of small heap structures for every possible codec, RTCP interceptor, RTP header, header extension and internal component ^[8]. Third, the stack goes to the OS and opens random UDP ports for ICE candidate gathering and binding, so a typical configuration takes new network resources for each `PeerConnection` ^[9]. Thirty viewers arriving at once means CPU pinned by key generation, a ballooning connection tracking table, and a garbage collector working through the wreckage of every closed session ^[10].

The fix described is structural rather than a tuning knob. In the author's own system, RUSEON Core, the heavy work moved into an isolated singleton engine in `internal/webrtc/engine.go` ^[11]. The certificate is generated once at startup via `ecdsa.GenerateKey(elliptic.P256(), rand.Reader)` ^[12]; the argument for this is that the browser does not care how old the certificate is, only that the SDP carries a cryptographically valid fingerprint ^[13]. The codec registry is likewise built at startup and stops touching the heap on every connection ^[14].

The network change is the one with the most operational consequence. Instead of dozens of random ports, `webrtc.NewICEUDPMux` is attached to a single UDP socket, so one port serves the whole system ^[15]. The kernel multiplexes incoming STUN, DTLS and SRTP through one file descriptor and Pion sorts packets between ICE and WebRTC sessions in userspace ^[16]. The claimed result is no port exhaustion and no need to open a 50000-60000 range in the firewall ^[17], which is a reduction from 10,001 permitted UDP ports to one ^[19]. That is a firewall rule you can actually defend in a review.

Two caveats about the material. The supplied text carries no before-and-after measurements: no handshake latencies, no CPU figures, no viewer count at which the pooled design was retested ^[21], so the mechanism is convincing while the magnitude is unverified. And the piece describes both a singleton engine ^[11] and an engine pool built on `sync.Pool` ^[18], which are different strategies with different lifetimes; the excerpt is cut off mid-declaration of `WebRTCEnginePool`, so how the two fit together is not shown ^[20].

What to watch is whether your own handler does the tutorial thing. Grep for `NewAPI()` inside your HTTP path; if it is there, your capacity ceiling is set by ECDSA key generation and socket churn, not by egress.