How Rust Lets Us Monitor 30k API calls/min
blog.bearer.sh
How Rust Lets Us Monitor 30k API calls/min
1–10 of 81 posts
Re: How Rust Lets Us Monitor 30k API calls/min
#2That was a real issue we were struggling to solve. Feels like Rust was the right tool for the right job.
Re: How Rust Lets Us Monitor 30k API calls/min
#3I'm one of the engineers that worked on this. It was the first Rust production app code I've written so it was a really fun project.
Re: How Rust Lets Us Monitor 30k API calls/min
#4I'm one of the engineers that worked on this. It was the first Rust production app code I've written so it was a really fun project.
One of the interesting effects of using rust is saving money! I also migrate a F#/.NET ecommerce backend and can run in less RAM/CPU that make my bills lower.
Re: How Rust Lets Us Monitor 30k API calls/min
#5They didn't mention Java as a possible solution, even though its GC's are far better than anything else out there. I have nothing against Rust but if I was at a startup I would save my innovation points for where they're mandatory
Re: How Rust Lets Us Monitor 30k API calls/min
#6Sorry, I must be missing something in this blog post because the requirements here sound incredibly minimal. You just needed an HTTP service (sitting behind an Envoy proxy) to process a mere 500 requests/second (up to 1MB payload) and pipe them to Kinesis? How much data preparation is happening in Rust? It sounds like all the permission/rate-limiting/etc happens between Envoy/Redis before it ever reaches Rust?
I know this comes across as snarky but it really worries me that contemporary engineers think this is a feat worthy of a blog post. For example, take this book from 2003 [1] talking about Apache + mod_perl. Page 325 [2] shows a benchmark: "As you can see, the server was able to respond on average to 856 requests per second... and 10 milliseconds to process each request".
And just to show this isn't a NodeJS vs Rust thing, check out these webframework benchmarks using various JS frameworks [3]. The worst performer on there still does >500 rps while the best does 500,000.
It's 2020, the bar needs to be much higher.
[1] https://www.amazon.com/Practical-mod_perl-Stas-Bekman/dp/059...
[2] https://books.google.com/books?id=i3Ww_7a2Ff4C&pg=PT356&lpg=...
[3] https://www.techempower.com/benchmarks/#section=data-r19&hw=...
Re: How Rust Lets Us Monitor 30k API calls/min
#7They didn't mention Java as a possible solution, even though its GC's are far better than anything else out there. I have nothing against Rust but if I was at a startup I would save my innovation points for where they're mandatory
> I have nothing against Rust but if I was at a startup I would save my innovation points for where they're mandatory
An article published today, addressing that exact point: https://tim.mcnamara.nz/post/621040767010504704/spend-your-n...
Re: How Rust Lets Us Monitor 30k API calls/min
#8They didn't mention Java as a possible solution, even though its GC's are far better than anything else out there. I have nothing against Rust but if I was at a startup I would save my innovation points for where they're mandatory
It's not like Elixir doesn't benefit from a battle hardened VM since it's older and has been used in these kind of high volume scenarios before Java was.
Re: How Rust Lets Us Monitor 30k API calls/min
#9Having never dealt with issues relating to garbage collection before, how do you go about diagnosing GC issues in a language where that’s all handled for you?
Re: How Rust Lets Us Monitor 30k API calls/min
#10Sorry, I must be missing something in this blog post because the requirements here sound incredibly minimal. You just needed an HTTP service (sitting behind an Envoy proxy) to process a mere 500 requests/second (up to 1MB payload) and pipe them to Kinesis? How much data preparation is happening in Rust? It sounds like all the permission/rate-limiting/etc happens between Envoy/Redis before it ever reaches Rust? I know…
I hope some day doing something trivial using rust will no longer warrant a hacker news post to promote a startup.