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
:gununder the hood
- reconnect and rejoin mechanisms with back-off similar to
- a rich set of
- utilities for testing clients similar to
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.