Great, I can use this for that blogging app I've been meaning to write and sleep at night knowing I won't run out of connections.
Achieving 100k connections per second with Elixir
91–100 of 117 posts
Re: Achieving 100k connections per second with Elixir
#92I'd love to see data on the average on-call incidents for an application written in language X (say Go) vs those written in Elixir. Concretely, its it the case, for an application where Elixir/Erlang/Beam are a great choice, but also, another language would be fine, that the equivalent Elixir application results in less downtime/pages than the alternative. Anything from the perfect app to something with a ton of race…
> I'd love to see data on the average on-call incidents
Don't have any hard data to compare but having been involved in debugging running Erlang systems. It's very nice having the ability to restart separate supervisors while the rest of the processes handle requests. Being able to do hot code loading to say fix bugs or add extra logging. And my all time favorite -- live tracing after connecting to a VM's remote shell. You can just pick any function, args, and process and say "trace these for a few seconds if a specific condition happens". None of those individually are earth shattering but taken together they are just so pleasant to use. I wouldn't enjoy going back to anything didn't those capabilities.
And yes, that restarting of sub-systems (supervision trees) happens automatically as well. There were a number of cases were it turned a potential "wake up 4am and fix this now, cause everything crashed" into a "meh, it's fine until I get to it next week" kind of a problem.
Re: Achieving 100k connections per second with Elixir
#93I can handle 120k connections per second with my custom made, highly optimized multiprocess C++ server. But the main problem is business logic. Just make 2 SQL queries to MySQL on each HTTP request and look at how it will degrade.
There are simple tricks to make those queries not kill performance. Here is a dumb proof-of-concept I made a few months ago: https://github.com/MatthewSteel/carpool
The general idea is combining queries from different HTTP requests into a single database query/transaction, amortising the (significant) per-query cost over those requests. For simple use-cases it doesn't add a whole lot of complexity, can reduce both load and latency significantly, and doesn't lose transactional guarantees.
Not 100k/sec writes on my laptop, mind you :-).
Re: Achieving 100k connections per second with Elixir
#94Earlier quoted context omitted.
We used Ubuntu 18.04 with the 4.15.0-1031-aws kernel, with sysctld overrides seen in our /etc/sysctl.d/10-dummy.conf. We used Erlang 21.2.6-1 on a 36-core c5.9xlarge instance. To run this test, we used Stressgrid with twenty c5.xlarge generators.
Did starting more acceptors than the number of cores make any difference?
Author here. We tried number of acceptors that was 4x and 16x number of cores without any difference.
Re: Achieving 100k connections per second with Elixir
#95I can handle 120k connections per second with my custom made, highly optimized multiprocess C++ server. But the main problem is business logic. Just make 2 SQL queries to MySQL on each HTTP request and look at how it will degrade.
There are simple tricks to make those queries not kill performance. Here is a dumb proof-of-concept I made a few months ago: https://github.com/MatthewSteel/carpool The general idea is combining queries from different HTTP requests into a single database query/transaction, amortising the (significant) per-query cost over those requests. For simple use-cases it doesn't add a whole lot of complexity, can reduce both lo…
Looks interesting! You mentioned in the docs that it would be simpler once abstractions develop and that made me realize it's similar to facebook/dataloader, just used across requests instead of batching up all of the queries per request. It's also of course a generalized form of it that represents batching a parametrized method more so than just batching retrievals by some kind of unique key. It may be able to serve as something to lift API ideas from though. Like some kind of BatchedTask that has an execute() method that takes an array of args then batches those into an array of array of args for the underlying batched implementation.
https://github.com/facebook/dataloader/blob/master/README.md
Re: Achieving 100k connections per second with Elixir
#96Is Elixir/Erlang considered superior to Go for writing high concurrency web servers?
Not na expert in any of the languages by any means, but Go and Erlanger/Elixir focus on different things: - Go wants to be performant at high concurrency scale - Erlang/Elixir wants to keep running at high concurrency scales, whatever the issues are in your application code. Performance comes second. There's no clear cut answer to your question; I guess if you trust yourself to write servers that will hold a large nu…
> Performance comes second.
I want to state that performance is too generalize here.
BEAM VM also have a goal of low latency which can be consider as performance. I'm not entirely sure if GO is aiming for that or not. I would never do any numerical stuff on BEAM though, it's very slow.
This article is a bit dated but is interesting between Go and Erlang:
https://www.theerlangelist.com/article/reducing_maximum_late...
Re: Achieving 100k connections per second with Elixir
#97I can handle 120k connections per second with my custom made, highly optimized multiprocess C++ server. But the main problem is business logic. Just make 2 SQL queries to MySQL on each HTTP request and look at how it will degrade.
There are simple tricks to make those queries not kill performance. Here is a dumb proof-of-concept I made a few months ago: https://github.com/MatthewSteel/carpool The general idea is combining queries from different HTTP requests into a single database query/transaction, amortising the (significant) per-query cost over those requests. For simple use-cases it doesn't add a whole lot of complexity, can reduce both lo…
[deleted]
Re: Achieving 100k connections per second with Elixir
#98Id like to see memory consumption charts for this. It seems you miss this on all your posts. Not a criticism (and thank you for what you have done), its just something I (and others) would like to see, and if you are running the tests its just another metric to log :D
Also, any update on your previous article? https://news.ycombinator.com/item?id=19094233
Re: Achieving 100k connections per second with Elixir
#99im a simple man. i see Elixir, i upvote. that being said, this article was pretty informative. The bit about the proposed SO_REUSEPORT socket option was really interesting. Really fun to read about performance bottleneck detection and improvement. edit: wow, downvoting for making a simple joke about liking elixir. Cool.
I've found that humor in comments on HN is usually not well received. Not sure why, just an observation.
Re: Achieving 100k connections per second with Elixir
#100Earlier quoted context omitted.
Can you show me your example code? Also, assuming it scales up linearly is a bit risky, although I agree with that kind of conn/s I am sure it will be sufficient.
Nothing special, just usual asyncio Protocol with uvloop policy.
I would love to see the code.