5M Bid request/s, 2ms max response time – The Road to Damascus

Re:5M Bid request/s, 2ms max response time – The Road to Dam... by nullwasamistake on Friday May 24, 2019 @06:57PM (#20006014)

I mentioned this elsewhere in the thread, but since you'll see the reply here; look into Vert.X if you haven't already.

It already does most of what you want and has support for native epoll transport.

I'm not sure what led Vert.X to be discarded, maybe not a Java shop? But we've used it extremely successfully for high performance REST and I know of several high profile tech companies that swear by it.

There's nothing I know of that compares with Vert.X in performance, stability, and popular adoption

[ Parent | on HN ]

Re:5M Bid request/s, 2ms max response time – The Road to Dam... by rkallos on Friday May 24, 2019 @08:29PM (#20006392)

Thanks for the recommendation! However, there are a few reasons why Vert.X wasn't considered, the biggest ones being that we're not a Java shop and the service in this blog post isn't HTTP/REST.

While the bandwidth benchmarks are fun to see and write blog posts about, we also care a lot about keeping tail latency at or below 2ms than we do about getting more bandwidth at this point.

[ Parent | on HN ]

Re:5M Bid request/s, 2ms max response time – The Road to Dam... by nullwasamistake on Friday May 24, 2019 @08:52PM (#20006464)

Ah yes. The GC latency could be a problem. Java may still be viable with the new ZGC garbage collector. And Vert.X uses Netty underneath which is mostly protocol agnostic.

Still, those issues and not being a Java shop makes Vert.X/Netty likely a bad fit.

Thanks for replying with a well thought out response!

[ Parent | on HN ]