Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

about max #connections #14

Closed
iamyellow opened this issue Sep 6, 2015 · 4 comments
Closed

about max #connections #14

iamyellow opened this issue Sep 6, 2015 · 4 comments

Comments

@iamyellow
Copy link

hi! before all, thanks for your work... i have an eye on this project since almost its first day, very well written, and having a xmpp client somehow proxied server-side is very good/clever idea. congrats for that!

i'm not a sysadmin guy and don't have networking knowledge enough to find an answer by myself, so i'd like to ask you something that maybe is pretty basic. AFAIK there's a max number of (TCP) connections per system, i'd say 64K per client per server port or something like that. so, in the following scenario:

  • mobile/web clients are connecting to a cowboy/phoenix server through websocket connection
  • once the connection is stablished, w/ hedwig we start an xmpp client to
  • (e.g.) an ejabberd server running in the same physical server
    i understand a TCP connection is opened client<>wsServer, and another wsServer(process)<>ejabberd. do you know if those local/internal connections between hedwig and ejabberd are somehow affecting our max number of open connection? in other words, per user we would have 2 connections, then max number of possible user connections: 32K.

also, we know that BEAM also has a max of processes, and having at least 2 (erlang) processes per user is a fact, but this is more tweak-able :)

@scrogson
Copy link
Member

scrogson commented Sep 8, 2015

@iamyellow thank you for the kind words.

You bring up a fantastic problem! I'm not very knowledgable in this area, but I am at least familiar with it.

The websocket connections would be from a browser client to your phoenix server and then the hedwig clients would connect to ejabberd. So the limit would be in the connections between hedwig and ejabberd.

I believe it ultimately comes down to file descriptor limit. Have a look at this SO answer: http://stackoverflow.com/a/2332756

If you are running both your phoenix app and ejabberd on the same server, I suppose you'd run out of file descriptors much quicker. So separating these may give you more mileage.

This is a problem I definitely want to tackle. Thanks for starting this issue!

@iamyellow
Copy link
Author

pleased my question helps to improve this work :)
it could be interesting to try what will happen with the limits dockerizing both ws server and ejabberd, maybe a container 'reset' the limit so we can have both services in the same machine. i'd like to push hardware to its limits hehehe

@cigzigwon
Copy link

cigzigwon commented Dec 20, 2021

@scrogson Is anybody working on a client adapter for Websockets? I was thinking of building an interface to the Websockex lib. I want to implement Hedwig to be our new responder for our flagship app. In our case we don't actually rely on Phoenix Channel spec but just :cowboy_websocket behavior. In theory having a basic :hedwig_websockex adapter would be a starting point? I'm willing to PR but have not began the process of coding. It looks like the adapter just needs to have an interface impl like the XMPP adpater but just focus on basic Websockex send/recv because that's all we really need for both Cowboy and Phx Channels. Thoughts? Right now our product uses Websockex for functional tests w/our backend so everything is well understood at this point. We are an emerging tech company and we have chosen Hedwig to answer the door. Thanks!

@cigzigwon
Copy link

cigzigwon commented Dec 20, 2021

Looks like I just need to clone/copy the :hedwig slack lib and remove things besides the connection inteface and then replace :websocket_client w/Websockex, that's what we will do to make this work for our use case regardless... Let me know if you want it PR I will share my repo when I', done w/testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants