The Phoenix/LiveView-based product that my company makes has a very unusual usage profile. For months at a time, any particular customer will make very light usage of it. Until, suddenly, 20, 50, or even 100 or more users will start pounding on the product at once. This will last for 1-3 weeks before going silent again. This is expected and not a big deal.
However, the industry we serve is such that when these, say, 50+ people are hammering away, they are physically together in the same room as they do so! Furthermore, our customers are not tech savvy and so they tend to all be connected to the same under-powered office WiFi access point.
If this was a normal web application, then that wouldn’t be a problem. But with LiveView I now have 50+ people sitting inches away from each other and trying to keep a persistent websocket connection in place, all while uploading/downloading gigabytes of data per day. The result is calls to our support line saying the product is slow, when in reality they have an oversaturated access point and probably a great deal of EM interference.
What I’d like to do in this situation is simply notify users that their connection is wobbly and provide a link to instructions on how they can mitigate this. I experimented with JavaScript’s navigator.connection property (Chrome only, but that’s okay) and that might be enough. But it didn’t seem to notice when I enabled the liveview socket’s enableLatencySim, and I’m not sure if it should have.
In any event, I’m wondering if anyone else has dealt with this and what solutions you have come up with?
This is a pretty hacky idea, but perhaps you could use Phoenix Presence to detect when a lot of users from the same organization or IP address are present at the same time, and just pre-emptively send a warning when a certain simultaneous user count is reached.
Obviously not the most practical idea, but if nothing comes up, it may be a workable (and easy-to-implement) solution.
I’m not familiar with navigator.connection, but you could perhaps use Chrome’s throttling it it’s DevTools for something which is probably lower-level than what Phoenix/LiveView can simulate:
Also, have you done any optimization of your LiveView? Sometimes it does some annoyingly inefficient things when sending data over the wire. This presentation has some tips on how to help with that:
Also, they’ve been introducing some optimizations in newer versions of LiveView which take care of optimization in some cases with you having to do anything, so upgrading might help.
Unfortunately, the “mitigation” entails telling people to call IT and have them bring in some switches and ethernet cables. And, yeah, the groupings are dynamic and not known in advance.
There’s plenty of room for us to optimize LiveView, but I’m certain the problem would still exist. It’s really a matter of too many people transferring too much data over too many connections on a single AP. Exacerbated by many of those connections (though not the file upload/download ones) being persistent LiveView sockets.
I’d say it’s not the job of the server to notify the user if their connection is slow. It’s the job of the client. You should somehow observe the network requests and determine if they’re slow enough to notify the user.
Unfortunately, with LiveView running on a websocket, I don’t have any ideas how to do the above.
I also recall a talk in which Chris McCord demos a LiveView showing live latency to clients around the world, but I couldn’t find it now.
Probably the best integration points would be global code in app.js monitoring client network performance, or a client Hook. In the absence of a better idea, you can measure pings between client and server and use that to trigger adding a CSS class/JS command to show the message about contacting IT, etc.
Honestly, this sounds like a pretty feasible solution. It is rather easy to implement and you could simply configure the amount of connections before an info message appears, notifying the end user, that there are many connections from a single IP.
