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

Anyone using this in production? #1

Open
gabegorelick opened this issue Apr 28, 2016 · 7 comments
Open

Anyone using this in production? #1

gabegorelick opened this issue Apr 28, 2016 · 7 comments

Comments

@gabegorelick
Copy link

The code looks good, but I'm curious how battle tested this is.

@thedillonb
Copy link
Owner

Good question. I'm not sure. I use it for my projects and that serves some live traffic. But it's by no means at the scale of a large project or corporation might put it into.

@nfantone
Copy link

nfantone commented Jul 2, 2016

We use it, on multiple APIs we have. None of them very large, though. No problems so far.

Sorry for hijacking this, but I'd love to know if this would be support https instead of http. Or even http2/spdy.

@riston
Copy link

riston commented Jul 4, 2016

Haven't used this module yet, but do you see any problems storing the separate connections map in your code. The Node.js connection timeout is quite long and if someone floods with keep-live TCP connections would it run out of memory? Have you measured the memory usage with some benchmark tests?

@ehynds
Copy link

ehynds commented Aug 24, 2016

Some anecdotal evidence here fwiw.. I tested my app using siege with and without this module, flooding it with 1000 simultaneous requests over 100k requests. Unsurprisingly it created 1k sockets and kept them all open for the duration of the test. The difference in memory usage was negligible.. if you're worried about being hit with a flood of keep-alive requests then there are probably better optimizations to make (tweaking http.globalAgent.maxSockets could be one of them).

@nfantone
Copy link

nfantone commented Aug 25, 2016

I tested my app using siege with and without this module, flooding it with 1000 simultaneous requests over 100k requests. Unsurprisingly it created 1k sockets and kept them all open for the duration of the test.

@ehynds Correct me if I am wrong, but I believe you're missing the point of this module. It's not meant to handle keep-alive connections in any way, but terminate them gracefully on server shutdown if they are still active. It won't affect your uptime execution at all.

@thedillonb
Copy link
Owner

This module simply keeps a reference to the open sockets within a running http server. Resource consumption is incredibly small. If you think you'll have 1k sockets open then this module will keep track of 1k worth of references. I'd be hard pressed to even see a difference in memory consumption with this module and without in a running http server - it's that negligible.

@ehynds
Copy link

ehynds commented Aug 25, 2016

Yes, I get that, poor word choice. My point was that 1k sockets were created and recycled over the course of my test and this module holding references to them had an indiscernible impact on memory usage.

Sent from my iPhone

On Aug 24, 2016, at 9:41 PM, Dillon Buchanan notifications@github.com wrote:

This module simply keeps a reference to the open sockets within a running http server. Resource consumption is incredibly small. If you think you'll have 1k sockets open then this module will keep track of 1k worth of references. I'd be hard pressed to even see a difference in memory consumption with this module and without in a running http server - it's that negligible.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

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

5 participants