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

Optimize goroutine and memory usage #47

Open
troian opened this issue Aug 31, 2017 · 3 comments
Open

Optimize goroutine and memory usage #47

troian opened this issue Aug 31, 2017 · 3 comments
Assignees

Comments

@troian
Copy link
Member

troian commented Aug 31, 2017

Currently active connection requires 4 running goroutines with 4K of stack per each plus incoming ring buffer of 8K. If scale to 1M active connections we get into 12G of memory. If client does send nothing and no publishes for subscribed topics it just waste of memory. Reasonable to optimize by packing into less goroutines and spin them only when events available.

  1. Receiving packets. If there is no data on socket it blocked on epoll until there is some data. On github.com/golang/go, there is the issue. Wait until it's completed

  2. Sending goroutine spin only when there is messages to transmit otherwise it should be down

@troian troian self-assigned this Aug 31, 2017
troian added a commit that referenced this issue Aug 31, 2017
Omtimize send/recv routines

Signed-off-by: Artur Troian <[email protected]>
@ddatsh
Copy link

ddatsh commented Sep 2, 2017

greate idea

@funny-falcon
Copy link

funny-falcon commented Jun 24, 2018

There are existed experience with using epoll explicitely for websocket server:
https://medium.freecodecamp.org/million-websockets-and-go-cc58418460bb

@troian
Copy link
Member Author

troian commented Jun 26, 2018

Was using it for a bit in the project. Still does not comply with all the requirements for example DeadLines does not work properly. Btw, did you get them working?

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

No branches or pull requests

3 participants