6 ms·
Is this complete note? You didn't mention what you end up using. Is it golang or pony or F$? CoreFX mention in the end confused me more.
by w3clan 7y ago
Is this complete note? You didn't mention what you end up using.
Is it golang or pony or F$?
CoreFX mention in the end confused me more.
- tracker1 7y ago> "I didn't want to rewrite everything from scratch, and definitely, I didn't want to handle all edge cases for epoll. My choice was to use libuv. The architecture I opt for: use 16 cores out of 40 for networking, having 16 'uv_loop' each running on its own thread. Callbacks will be passed from F# to each 'uv_loop' instance. The event loop will call them after parsing the bid request in C11." Looks like libuv directly in C11? (not F# as before edit).
- bbernoulli 7y ago> The solution was to Marshal calls from F# to libuv and achieve 5 Millions (at least) bid requests/s on 16 threads (this solution scales with cores/NICs).
- rkallos 7y agoI work with Wael. Development is still ongoing. One implementation uses Golang, the other uses F# with a library that wraps libuv for faster network performance. Pony was used to write the stress-testing client for both implementations.
- deforciant 7y agoDo you use libuv on go side as well?
- spooneybarger 7y agoI'm really glad I came here and found this comment. It squares so many circles for me. Thanks rkallos.
- rkallos 7y agoThanks for helping me answer all my questions about Pony! :)
- spooneybarger 7y agoYou're welcome.
- nullwasamistake 7y agoI 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
- rkallos 7y agoThanks 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.
- nullwasamistake 7y agoAh 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!
- tybit 7y agoWas pony considered for the implementation itself? Other than the immature ecosystem it seems like a perfect fit here. Awesome write up and sounds like a fun job.
- dom96 7y agoHave you considered Nim? You can achieve some really high performance with it[1]. Since you've considered Rust, Go, C and even Pony, Nim should really be on your list. 1 - See httpbeast in the latest round of the Techempower benchmarks: https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r17&hw=...
- BubRoss 7y agoDoes Nim's compiler still crash all the time? Also why is evey immature native language considered, but the two speed demon languages without garbage collection - ISPC and C++ - are nowhere to be found?
- philliphaydon 7y agoF$???? Is that a typo?
- kuroguro 7y agoCould be a play on "M$"? A typo is probably more likely since the keys are next to each other.
- insulanian 7y agoThe language is called F# (pronounced F-sharp), not F$.