Adding websockets to existing application

Question

So I wrote this nice SAAS solution and got some real clients. Now a request was made by a client to add some functionality that requires websockets.

In order to keep things tidy, I would like to use another server to manage the websockets.

My current stack is an AWS application loadbalancer, behind it two servers - one is the current application server. It's an Apache web server with PHP on it running the application.

The client side is driven by AngularJS.

The second server (which does not exist yet) is going to Nginx, and session will be stored on a third Memcache server.

Websocket and application server are both on the same domain, using different port in order to send the requests to the right server (AWS ELB allows sending requests to different server groups by port). Both the application and websockets will be driven by PHP and Ratchet.

My questions are two:

• is for the more experienced developers - does such architecture sounds reasonable (I'm not aiming for 100Ks of concurrent yet - I need a viable and affordable solution aiming to max 5000 concurrents at this stage).
• What would be the best way to send requests from the application server (who has the logic to generate the requests) to the websocket server?

Please notice I'm new to websockets so maybe there are much better ways to do this - I'll be grateful for any idea.

Answer 1

I'm in the middle of using Ratchet with a SPA to power a web app. I'm using Traefik as a front-end proxy, but yes, Nginx is popular here, and I'm sure that would be fine. I like Traefik for its ability to seamlessly redirect traffic based on config file changes, API triggers, and configuration changes from the likes of Kubernetes.

I agree with Michael in the comments - using ports for web sockets other than 80 or 443 may cause your users to experience connection problems. Home connections are generally fine on non-standard ports, but public wifi, business firewalls and mobile data can all present problems, and it's probably best not to risk it.

Having done a bit of reading around, your 5,000 concurrent connections is probably something that is going to need OS-level tweaks. I seem to recall 1,024 connections can be done comfortably, but several times that level would need testing ( eg see here , though note the comment stream goes back a couple of years). Perhaps you could set up a test harness that fires web socket requests at your app, eg using two Docker containers? That will give you a way to understand what limits you will run into at this sort of scale.

Your maximum number of concurrent users strikes me that you're working at an absolutely enormous scale, given that any given userbase will usually not all be live at the same time. One thing you can do (and I plan to do the same in my case) is to add a reconnection strategy in your frontend that does a small number of retries, and then pops up a manual reconnect box (Trello does something like this). Given that some connections will be flaky, it is probably a good idea to give some of them a chance to die off, so you're left with fewer connections to manage. You can add an idle timer in the frontend also, to avoid pointlessly keeping unused connections open.

If you want to do some functional testing, consider PhantomJS - I use PHPUnit Spiderling here, and web sockets seems to work fine (I have only tried one at a time so far, mind you).

There are several PHP libraries to send web socket requests. I use Websocket Client for PHP , and it has worked flawlessly for me so far.