Interesting details; it would be nice to see how those ulimit/networking numbers were arrived at. The title should have [2015].
Yep - title should've had [2015], my bad!
Added now.
600k concurrent websocket connections on AWS using Node.js (2015)
121–130 of 141 posts
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#122Earlier quoted context omitted.
It's not about which is the best technology. The barrier to entry for Node.js is next to nothing and the size of the ecosystem is incomparable to Elixir. Which means tons of companies will go with Node and feed back to the ecosystem and so on...
If we are going on size of ecosystem/what companies are invested in/etc, then you may as well stick with Java and the JVM with something like Vert.x. No need for Node.
nodejs ecosystem is much larger than the java one. also the amount of money companies invested in node is at least on par with java. think only about google chrome.
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#123I don't get point of using Node.js when compared to something like Elixir. Elixir's Phoenix can handle more numbers of concurrent connections as well as provide reliability with better programming abstractions, distribution, pretty good language.
It's not about which is the best technology. The barrier to entry for Node.js is next to nothing and the size of the ecosystem is incomparable to Elixir. Which means tons of companies will go with Node and feed back to the ecosystem and so on...
> The barrier to entry for Node.js is next to nothing
Assuming existing experience with JS / npm / async style. If you don't have that, I'm not sure which would be harder to start with. Given a little bit of experience with each, I'd actually lean towards elixir being a simple choice. Then again it depends on whether you're cool with training new devs in case of lack of elixir people.
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#124Does anyone have a more recent experience? I currently use socket.io 2.2 with node v10.16, no v8 tweaks in a docker container. At ~1000 sockets, sometimes the server receives spikes of 8000 HTTP reqs/sec, which it has to distribute to the websockets, up to 100 msgs/sec, ~1kb/msg to each socket. These spikes are making the server unstable, socket.io switches most of the clients from websockets to xhr polling.
I don't have any experiments to share, but you can go father if you stop using socket.io, but I guess you need something to deal with long polling. You should consider tweaking --max_old_space_size, we got a lot of mileage giving node more memory.
I make heavy use of socket.io chatrooms and have to support older browsers. Haven't found any better solution yet, but I'll try the tweak, thanks. I'm also looking into load balancing via haproxy or nginx, since I need less than 10k concurrent clients.
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#125I did this with Netty back in 2010. Increasing nf_conntrack_max is a hard-learned lesson.
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#126So 1/4 of what Elixir/Erlang can handle, but more difficult and less reliable: https://phoenixframework.org/blog/the-road-to-2-million-webs...
"but more difficult" sounds pretty subjective... I can get behind the "less reliable" comment because Erlang is rock solid. Sorry to be that guy, but I can find a TON more people capable of supporting ECMA vs. Erlang and/or Elixr. I say this as a huge fanboy of both. I know I'll get rolled on HN for saying this because we all drink the optimization Koolaid but I feel this is worth mentioning.
You have a fair point, but if by "more difficult" the grandparent meant "more difficult to maintain", I'd have to agree with him. The failure modes of processes running in the BEAM are much more transparent and understandable than the usual ad-hoc JS nodejs server.
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#127Earlier quoted context omitted.
"but more difficult" sounds pretty subjective... I can get behind the "less reliable" comment because Erlang is rock solid. Sorry to be that guy, but I can find a TON more people capable of supporting ECMA vs. Erlang and/or Elixr. I say this as a huge fanboy of both. I know I'll get rolled on HN for saying this because we all drink the optimization Koolaid but I feel this is worth mentioning.
You have a fair point, but if by "more difficult" the grandparent meant "more difficult to maintain", I'd have to agree with him. The failure modes of processes running in the BEAM are much more transparent and understandable than the usual ad-hoc JS nodejs server.
IMO they're on the same level but I think it's just my style of how I manage my Node.js applications down my try/catch blocks, exception handling, and primarily process isolation.
> usual ad-hoc JS nodejs server
Yep - that's the key why I feel they're on the same level. I heavily rely on the cluster module and IPC to get my work done which gives me true process isolation/safety however I admit it's more code in Node.js to make it rock-solid ;)
Anecdotal, but I find that the typical Node.js developer is 100% "single-process" with weird supervisors like PM2. I also see over-engineered fleets of EC2 instances behind ELB/ALBs with health checking kicking bad instances out + a way to replace them... this is also stupid common in Docker/docker-compose/K8s as well.
For the record I think that development pattern described in the above paragraph is total crap and I put it on the same level of idiots giving modern PHP7 a bad name. Devs who practice like this completely blew the content from their CS100/200 level courses out their butt (yeah yeah I say this as a dropout myself whatever ha).
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#128Earlier quoted context omitted.
Well, Node.js is just good tech with a simple async-everything concurrency model.
Ya. nodejs is "JavaScript bindings for libev". Deno (also by Ryan Dahl) "TypeScript bindings for libev" may become a viable successor. https://deno.land/manual.html#introduction
let’s hope so! Looks like a great project
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#129Earlier quoted context omitted.
DNS round robin has the disadvantage of not guaranteeing that the traffic will be equally distributed. This can be a problem if there's a lot of automated traffic. But, with that said, in term of price, it's unbeatable.
The point is at scale you can't guarantee equal but something around there
That works well, but if you do ecommerce or a web app for which people write a lot of bots, then the traffic won't necessarily be that well distributed (mostly because users while run bots out of dedicated servers or such and will tend to only query dns once).
A bit of an edge case but pretty much the only issue I've had so far which is why I bring it up.
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#130Earlier quoted context omitted.
Could you explain or post a link to something about #2? I’ve never heard of that before!
I can not. AWS, for whatever reason, does not want this publicly documented. I would write up what we learned in our testing in more detail, but I have been asked not to. You can find some discussion of this behavior in places like https://forums.aws.amazon.com/thread.jspa?threadID=231806 . I originally became aware of the issue, before hitting in production, from the HN comment at https://news.ycombinator.com/item?i…
Their response displeases me.