Backpressure event to end client connection and Pubsub backpressure

[aviadhadidainx]

Hi.

First of all I was checking the issue with NPM for a long time. It was a major concern and after we investigated a bit we decided to go with you!.
We are building Crypto + Security tokens platform that we expect to be one of the top 10 Exchanges (https://inx.co)

For our API Clients we would like to use your awesome lib.

Major questions:

1. I think that in our case if someone has a large backpressure(1024 queued messages) We would like to disconnect his session

   • How would you suggest to tackle this? Just check the ws.getBufferedAmount() and call .end() if is more than X ?

2. You mentioned that the pub sub automatically neglect some messages in case of backpressure limit.

   • Is there any case to make it manually? To decide what to do in such case? like close the problematic websocket

3. If we built in memory mapping for channels instead of the pub sub, what will be the impact? Is there any performance differences assuming we will use map for each channel with list of websockets?
   e.g Let's assume I have 2 websockets connections that subscribe to the same channel, what will be the differences between those 2 implementations :
   a. ws1.send(message) + ws2.send(message)
   b. uws.publish(channel)

4. What is the process of supporting your project. In our company we would like to be a supporter and to be in your portfolio

[ghost]

Hello,

If you have an idleTimeout of say 60 seconds, and some slow receiver causes ton of backpressure it will eventually be closed since sends will be skipped and then it will be marked as idle and closed. If you receive data from the slow receiver you can check backpressure and close right away.

So you can make things work with current version - but I want to add an option to make it close the connection instead of skipping sending. That's something that could be added but you could solve the issue like mentioned above already.

3 is complex. I have posts about this. In a nutshell the idea is to do as much as possible in native code and only expose very abstract interfaces for the (script) developer so that internal algorithms can be tweaked for the better without putting that on the (script) developer. I have reports of real world production users that experience better performance with the pub/sub than doing it in script with send.

uNetworking AB is a Swedish corporation so we can set up anything, it really depends on what you want. We can continue this over mail. I do have tons in my pipeline right now though.

[aviadhadidainx]

Thanks for your reply.

1, 2 - Got it.. Agree that i have some workarounds to get the required behavior.
3 - Maybe can you give me some article links? In general based on what you said I Think i will use only pub sub.
For example: On connect i can subscribe to something like /user/{userId} and then if i want to send message to user i will use publish.
So I think send will never be used. Just to make sure, can you verify that this is a good approach based on what you know?

I will send you mail and wait patiently for my turn.

[ghost]

For example: On connect i can subscribe to something like /user/{userId} and then if i want to send message to user i will use publish.
So I think send will never be used. Just to make sure, can you verify that this is a good approach based on what you know?

That's not a good idea. Use send if you only expect one single connection per that one topic. Use pub/sub if you expect more than 100. Every topic has significant overhead and is poorly optimized for only holding 1 single connection. You can mix send and publish.

[aviadhadidainx]

Got it.. Thanks a lot.
100 is rough number or i can use it as a strict "rule"?

[ghost]

100 is more than a handful.

[hst-m]

I ran the load_test echo benchmark with 1000 connections for 3 cases:

182K msg/sec - ws.send
174K msg/sec - app.publish single socket topic
174K msg/sec - map/set ws.send single socket set

ws.send was 5% faster than app.publish for single socket topic. Publish was same speed as single socket map/set in JS, so you could go either way if you have small groups of sockets

[aviadhadidainx]

Sure. Thanks for your time. It helps a lot to understand the implementation on my side.

[aviadhadidainx]

Thanks. LMK if you have any interesting results with the performance

…

On Sat, Dec 19, 2020 at 10:17 PM hst-m ***@***.***> wrote: I guess I will go back to doing Maps and Sets for ws groups of less than 100, see example #378 (comment) <#378 (comment)> I will try a performance test doing Publish with single ws per topic vs ws.send and see what difference is — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#414 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKQXZVPEAQPZMWFQVHXQKZTSVUC5LANCNFSM4VAJLZZA> .