We @ NFIBrokerage use websockets and Phoenix.Channels fairly extensively in production, serving well over 100k connections a week.
When we first started using websockets broadly between back-end services, we noticed an odd build-up of process memory in Phoenix.Channel server processes which we now presume to be a product of moving large amounts of data over-the-wire and a known issue in :websocket_client (see more in the Slipstream documentation). This and the at-the-time archival of the popular phoenix_gen_socket_client led us to write a new Phoenix.Channel client from scratch backed by :gun.
Enter Slipstream!
Slipstream touts
:gununder the hood- reconnect and rejoin mechanisms with back-off similar to
phoenix.js - a rich set of
:telemetryevents - utilities for testing clients similar to
Phoenix.ChannelTest - a
GenServer-like callback interface for client modules with default implemementations for all callbacks - a synchronous interface for scripting
- an ever-expanding examples directory with reference clients and tutorials
After cutting over the bulk of our socket clients to Slipstream, we’ve seen a marked decline in clients disconnecting from Phoenix.Channels as a result of the server disconnecting them (as opposed to the client gracefully disconnecting).
(That line at 02/02 13:20 marks the mass cutover. Note that the other disconnection reasons than “disconnected by remote server” are expected and are considered normal and desirable behavior. Remainders of “disconnection by remote server” denote deploys and restarts of services running Phoenix.Channels. Also note that this improvement is more likely an indirect result of switching to :gun: that the remote server has less memory pressure and is therefore more reliable, rather than a hypothetical bug in the :websocket_client implemementation which would force disconnects.)
We’ve been using slipstream widely in production for a little while now and want to share it with y’all! If you’re in the market for a new Phoenix.Channel client, look no further.
