Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Rust Lets Us Monitor 30k API calls/min

blog.bearer.sh

Post reply on HN
Print view View original

11–20 of 81 posts

Re: How Rust Lets Us Monitor 30k API calls/min

#11

Post by andrewzah »

eggsnbacon1 wrote: post #5

They 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

Rust doesn't have a GC; it uses an ownership model instead.

Ultimately in a startup it comes to what people are comfortable with. I personally would use Rust for something like this because I am comfortable with Rust. It's a perfect use case for it as well, imho.

Re: How Rust Lets Us Monitor 30k API calls/min

#13

Post by TheTank »

eggsnbacon1 wrote: post #5

They 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

One step beyond good Java GCs is to write fully zero-GC Java code. The advantage of it is complete control over your performance which means your software is going to be consistently fast. The disadvantage is that it is relatively difficult to obtain.

If you want to see an example of fully zero-GC Java, you can check out QuestDB on Github [1] - Disclaimer I work for QuestDB.

[1]https://github.com/questdb/questdb

Re: How Rust Lets Us Monitor 30k API calls/min

#14

Post by the8472 »

hobbescotch wrote: post #9

Having 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?

In the java realm you have very fine-grained GC logging that provides insight into the overall behavior of the GC and its different subcomponents. Then there are recording/debugging facilities that allow you to trace allocations, how long objects live, analyze the entire heap (including unreachable but not yet collected objects). And higher-level monitoring APIs separate from the logging and debugging stuff. You can also choose between collectors with different characteristics, trading between overall heap size, latency, utilization of CPU cores and other factors.

Re: How Rust Lets Us Monitor 30k API calls/min

#15

Post by 013a »

hobbescotch wrote: post #9

Having 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?

There are some general tricks that are language-agnostic, like allocating a huge "buffer" object when the app starts, the size of which is some significant portion of the memory you allow the process to use, which always has a reference, then storing references to other objects you need in that big object. In other words, circumvent the garbage collector.

Of course, this has its own issues, but I've seen it done in e.g. Go before. Its likely you'll inevitably end up with leaks, but if your service is fungible and can tolerate restarts, basically what you're doing is moving the "GC Pause" to be a "Container Restart" pause, which may be slower, but would happen less often. Some languages have ways to manually call the GC (Node is not one of them, afaik).

Re: How Rust Lets Us Monitor 30k API calls/min

#16

Post by andrewzah »

JoshTriplett wrote: post #7
eggsnbacon1 wrote: post #5

They 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...

Ah yes, a 236 word "article", that says to choose "boring old technology" and also to use Rust in the same breath.

This article should mention that rust isn't close to ready when it comes to web backends. As much as I love Rust, if I were running a startup or even a decently sized company I would always choose Rails. Now -that- is boring, old... and mature technology. Certain components could get re-written in Rust, certainly, but there's no reason to ignore a mature ecosystem from the start.

Re: How Rust Lets Us Monitor 30k API calls/min

#17

Post by the8472 »

013a wrote: post #15
hobbescotch wrote: post #9

Having 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?

There are some general tricks that are language-agnostic, like allocating a huge "buffer" object when the app starts, the size of which is some significant portion of the memory you allow the process to use, which always has a reference, then storing references to other objects you need in that big object. In other words, circumvent the garbage collector. Of course, this has its own issues, but I've seen it done in e…

Node allows you to call global.gc() if you enable that functionality with a separate argument. In many cases this is an anti-pattern that would make your application behavior worse rather than better, that's why you have to opt into that.

Re: How Rust Lets Us Monitor 30k API calls/min

#18

Post by chrischen »

mamcx wrote: post #4
didroe wrote: post #3

I'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.

Does Rust offer much of the same language features as F#?

Re: How Rust Lets Us Monitor 30k API calls/min

#19

Post by raphinou »

mamcx wrote: post #4
didroe wrote: post #3

I'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.

Can you share information about your experience? I'm currently working on a F# project, enjoying the functional approach, while having a lot of libraries available on the .Net platform. The |> operator is one I use all over the code, but Rust doesn't support custom operators. Is that annoying, or not at all? Is your code less functional and more imperative style due to Rust?

Re: How Rust Lets Us Monitor 30k API calls/min

#20

Post by akoutmos »

Great article and thanks for sharing! There are a couple of things that stand out at me as possible architecture smells (hopefully this comes across as positive constructive criticism :)).

As someone who has been developing on the BEAM for long time now, it usually sticks out like a sore thumb any time I see Elixir/Erlang paired with Redis. Not that there is anything wrong with Redis, but most of the time you can save yourself the additional Ops dependency and application network hop by bringing that state into your application (BEAM languages excel at writing stateful applications).

In the article you write that you were using Redis for rate limit checks. You could have very easily bundled that validation into the Elixir application and had for example a single GenServer running per customer that performs the rate limiting validation (I actually wrote a blog post on this using the leaky bucket and token bucket algorithms https://akoutmos.com/post/rate-limiting-with-genservers/). Pair this with hot code deployments, you would not lose rate limit values across application deployments.

I would be curious to see how much more mileage you could have gotten with that given that the Node application would not have to make network calls to the Elixir service and Redis.

Just wanted to share that little tidbit as it is something that I see quite often with people new to the BEAM :). Thanks again for sharing!

Post reply on HN