How does kamal-proxy handle web socket connections?

[brendon]

I had a problem with Passenger where I forgot that I needed to configure a special endpoint for /cable and my server was basically blocking up when I had enough web socket users as they blocked the main Passenger workers:

  location /cable {
    passenger_app_group_name spikeatschool_action_cable;
    passenger_force_max_concurrent_requests_per_process 0;
  }

I haven't seen any mention of special treatment in the Kamal / kamal-proxy environment of web sockets and particularly the /cable endpoint so I assume all is well in this regard? Or does special treatment still need to happen to ensure long running sockets connections don't consume all the Puma workers?

[kevinmcconnell]

You don't need to do anything at the Kamal Proxy level. WebSocket connections are proxied automatically to your app, and having (potentially lots of) long-lived connections is not a very significant burden on the proxy. In the Rails app, Action Cable will serve these without consuming Puma workers, so up to a certain scale you should be fine with the out-of-the-box behaviour. It should all work correctly by default.

If you find that the load of serving WebSocket traffic becomes a problem for your main app at some point, you could also split the cable traffic out to its own deployment, using Kamal's path-based routing to separate that traffic. But that's really an app-level concern; it doesn't involve any other settings in the proxy.

So tl/dr, you don't have to do anything :) Hope that helps!

[brendon]

Nice! Yes I was hoping that would be the case :D I was just sensitive to it because of my experience with Passenger! :D