Not that they shouldn't have used Java, I understand their application was already written in Java and it wouldn't make sense to use an unfamiliar language, but I do wonder about Javas' efficiency here.
Just to pick a random stack overflow post, as a little anecdata to go with anecdote https://stackoverflow.com/questions/44708704/netty-as-high-p... has someone who's complaining they were only hitting 50k POST/sec with Netty.
> You can buy a 1000MHz machine with 2 gigabytes of RAM and an 1000Mbit/sec Ethernet card for $1200 or so.
I think it's less about the web server choice and more about the architecture around pre-computing and caching certain results in memory and then asynchronously writing via a queue.
In other words, having 32/64 concurrent threads you won't get the throughput you want so agree there.
However, I'll elaborate on my point and why it's not just "use event loop".
If you block the event loop you can get catastrophic behavior, like your entire server acts as if it's a single threaded synchronous runtime.
However, even with not blocking the event loop, you need to have optimal IO __given a coroutine__. If you are waiting a bunch of ms for multiple network calls and also a db write within a coroutine, your latency is going to go up and you might not hit your latency requirements.
I was specifying that the architecture was taking these concepts into account and getting low latency on each request in a high throughput way by not blocking on writes, precaching info in server memory, etc.
If they had to go to a db and/or do other calculations per query instead of pre-caching regardless of 32/64 or using an event loop, it likely would have either created another bottleneck or the web server would bottleneck and they would not hit their RPS
However in practice it’s more around 4-6k because it’s doing database operations. Some end points are only 1500 rps while some of my read ops are in the 10-25k.
That said: it’s a good bit of writing & interesting