-
Notifications
You must be signed in to change notification settings - Fork 73
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
Comments
@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! |
pleased my question helps to improve this work :) |
@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! |
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. |
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:
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 :)
The text was updated successfully, but these errors were encountered: