Too many subscriptions to socket.io in JavaScript

Question

I am using streaming provided by a vendor using socket.io using the following code:

var socket = io.connect('https://streamer.vendor-company.com/');
var subscription = ['sub1', 'sub2', 'sub3', 'sub4'];
socket.emit('SubAdd', { subs: subscription });
socket.on("m", function(message) {
    console.log(message);
    var messageType = message.substring(0, message.indexOf("~"));
    if (messageType == someMessageType) {
        dataUnpack(message);
    }
    else if (messageType == otherMessageType) {
        anotherDataUnpack(message);
    }
});

The method dataUnpack and anotherDataUnpack perform some processing on the received message and display to the webpage. Now here, the array subscription may have around 45 subscriptions.

I want to know the affect on performance on my website. Does socket.io have some way for not flooding the client or are there any serious performance consideration? Is socket.io designed for such usage?

Updates

This is different from: Too many on-connection events with Socket.io, does it hurt? as mine is for Javascript/jquery and the question to which I gave link is for node.js.

The server is not under my control. Looking at jfriend00's answer, It seems that if I have 50 subscriptions and I get around 20-30 messages per sec, I need to handle this on client side. If so, what is the amount of incoming messages I should worry at? And if possible, any technique/strategy for handling high rate of incoming messages?

Hi Kashyap. Let me explain why my edit was correct, and why I will flag to a moderator if you revert it again. When writing a question, you're not just appealing for assistance in the short term: you are addressing a long line of future readers with a problem _they_ have too. Thus, the first thing they want to read in the question is what the problem is, and not an edit to explain what it is different to. Questions are also summarised in search results and tag lists, so it is ideal for the summary (the first sentence or two) to be a useful description of the problem. — halfer, Jun 23 '18 at 11:12
I'm an experienced editor here - I've edited around 47,000 posts, and I _know_ how editing works. I participate in question closing and Meta discussion, so I know the community operation pretty well too. Thus, it is frustrating for me to see my volunteer work rolled back, when I know the community is in support of it. I would ask that if you do not understand an edit on your post, and if the editor might be an experienced one, please ping them in the comments and _discuss_ it before rolling it back. I'm very happy to discuss any of my edits. — halfer, Jun 23 '18 at 11:14
Hello @halfer, I respect your experience and voluntary work. But in one of my past questions, I have experienced people marking it duplicate even when the title of the question is completely different. I even commented on it to demand explanation of how my question was even close to the duplicate, but the flag was still there... Keeping that in mind, I preferred to first mention why my question was not duplicate. But regarding your point of summarisation of question, I agree with you wont won't rollback your edits. Thanks for your efforts to keep SO clean and useful :) — Kashyap Kotak, Jun 23 '18 at 14:15
I hear you. People sometimes make wrong judgement calls about close/duplicate voting, but it is normally OK because any question can be reopened. Marking a question with an edit to explain why it is not a duplicate is OK (the UI even encourages it) but not at the expense of future readability. — halfer, Jun 23 '18 at 14:19
I even edited that question for why its not duplicate. Still there was no change... anyways... Will keep your point in mind now on... Thanks — Kashyap Kotak, Jun 23 '18 at 14:25
@halfer I asked a new question today on SO and got a latest example of above. https://stackoverflow.com/questions/51007978/echoing-php-variable-into-javascript-variable-prints-the-php-variable-in-html look at the comments of Philipp in the question. I don't know what fun these people get for marking a question duplicate without reading it. — Kashyap Kotak, Jun 24 '18 at 12:40
That question really is unclear, so it is no wonder it has got three "unclear votes". You seem to be asking how to get a PHP variable into a JS variable, and you say so explicitly in your penultimate paragraph, and then your post-script says explicitly that you are not wanting to do that. Your stated expected output says you do not want a ` — halfer, Jun 24 '18 at 17:38
I experience some frustration that you believe that people are wanting to close your question for "fun" - that accusation is completely wrong, and entirely without foundation. Your insistence that you can unilaterally declare something as on-topic is also incorrect - plenty of authors of off-topic questions want their question to remain open, mostly because they don't believe the rules should apply to their own questions. — halfer, Jun 24 '18 at 17:45
Finally, your comment replies under that question appear to be rather patronising ("look at the question carefully") and may not be sufficiently diplomatic to persuade readers that your question is worth re-assessing. I appreciate that it is unfair that question authors have to exercise far more patience and diplomacy than voters, but nevertheless, I'd urge you not to (appear to) pick fights in the comments. If you can edit the question now, to make it clear what you want, that would help a lot (and may get the question reopened if it is to close). — halfer, Jun 24 '18 at 17:53

jfriend00 · Accepted Answer · 2018-05-07T15:40:55.737

Does socket.io have some way for not flooding the client

No. If your server sends a message to the client, socket.io delivers it. It's all up to your server how many messages it sends and socket.io's job is to deliver every one of them you tell it to send.

or are there any serious performance consideration?

If you send a ton of messages to a ton of clients, that will potentially take a lot of processing and bandwidth. socket.io is just a messaging layer on top of webSocket which is a layer on top of TCP. So, if you send a socket.io message from server to a client or from server to all clients, it's one of more TCP packets being sent to the client(s). The only way to not flood the client is for your server to not send it more than it wants or can handle.

Is socket.io designed for such usage?

Socket.io is designed to reliably deliver messages from server to client or client to server. It just does what you tell it. If you tell it to deliver 1000 messages, that's what it will do.

If you have concerns about too many messages being sent to the client, then you need to modify your server to control that. For example, you might decide that a client should not be notified more than once every 5 seconds (for efficiency reasons). To implement that, you'd need an extra layer (of your own design) on the server. That is not something that socket.io has built-in features for.

If you're getting 20-30 messages per sec per subscription and each client has 50 subscriptions, that's 1000-1500 messages per second per client. That is indeed a lot and probably not sustainable at either the client side or the server side, especially on the server-side as you get lots of clients all doing the same thing. At 1000 messages per second, you have to process a message in under 1ms in order to keep from falling behind.

There are no special techniques for handling a high rate of incoming messages other than be extremely careful to limit what you do when each message arrives. For example, you would not want to be touching the browser DOM on each message. Perhaps you would queue them and modify the DOM in batch only once per second. Further advice would need to see what you're trying to do with these messages.

The better path would be to find a way to limit the number of messages being sent to each client, either by being smarter about what you subscribe to, finding ways to configure the subscription to not send you so much or creating an intervening server of your own that can be smarter about what is sent to each client.

Upvoting. Thanks for this explanation. Looking at your answer, I have one more question which I have updated in the question. Please have a look. Thanks again. — Kashyap Kotak, May 07 '18 at 08:54
@jfriend00-There is some misunderstanding here; I meant 23-30 messages in all, combining all subscriptions. But idea of queuing and not touching DOM in every message is useful. By the way, I am not performing any processor hungry operations on received messages. Just like extracting and displaying a special part in message which are received in format- "p1~p2~p3...~...p7~p8" (number showing message parts). — Kashyap Kotak, May 07 '18 at 16:44
@KashyapKotak - 23-30 msgs per second isn't so bad as long as you aren't changing the DOM on every one of them which causes relayout and repaint. So, maybe a queue with an interval timer that batch processes the messages queue every few seconds would work. As always with this kind of stuff, you'll ultimately just have to test on a slower device to see how you're doing. — jfriend00, May 07 '18 at 19:47

Too many subscriptions to socket.io in JavaScript

Updates

1 Answers1