On 6/9/2020 3:02 AM, Bogdan Popa wrote:
Alex Harsanyi writes: > Question 1: Based on this benchmark, is there any reason to chose anything > else but "drogon"? Even if one chooses the second best on that list, which > is "actix", they already loose about 6% performance and things degrade > quickly afterwards. The framework at position 10 is already half the speed > of the top one. My take on these benchmarks is all that matters is that the framework doesn't get in your way once you add business logic. The vast majority of "real" web applications out there don't (and most likely can't) do 50k rps.
Or anywhere close to that given more realistic database queries.
You can see that in the "multiple queries" and "data updates" tests where the results are packed closer together because the logic is closer to what a lot of database-backed web applications do and the database ends up being a bottleneck. A description of the requirements of each test can be found here: https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview If you know and are willing to deal with writing and maintaining C++ then drogon looks like it might be a great choice. > Question 2: Based on Bogdans message in this thread, it seems that most of > the performance improvement for the Racket benchmark comes from the nginx > configuration (which has nothing to do with Racket) and the next > improvement has to do with how the user program is written (by supplying a > "Content-Length" header). So, is this benchmark really testing the Racket > web server performance, or is it testing a very specific deployment? The largest improvement comes from making the Racket application take advantage of all the hardware threads on the machine. Because Racket doesn't currently have a way to share TCP listeners across places and because fork isn't natively supported (I mentioned that it works via the FFI earlier in the thread, but I believe it needs some support from the runtime (handling of `EAGAIN') to work efficiently and not cause a lot of churn) I did the next best thing: I made the benchmark run one Racket process for each thread[1] and added nginx as a load balancer in front. The nginx process listens on port 8080, forks one subprocess per core (which lets the subprocesses reuse the same port) and then proxies any incoming requests on that port to one of the Racket processes so every single request is ultimately served by the Racket app. What this means in terms of this benchmark is that, compared to others, we're actually paying a toll for using nginx here because its own workers are consuming resources on the machine, but, to my knowledge, we don't have a better alternative at the moment.
Hmm. SSL which can be tricky to set up right for Racket, but that's the only reason I can see for using a separate HTTP server. Multiple Racket applications *should* all be able to listen on the same port without having been spawned from the same ancestor process. If that isn't working now, something has gotten hosed.
I'm not sure what you mean by "sharing" a listener, but using a single listener with a pool of processing places actually is possible (though tricky). TCP ports can be passed among places, so a single listener instance can direct multiple processing instances. I don't know how passing off the port would interact with web-server response handling (I would think the listener place could just shut down / abandon the port and leave response to the process place but I have never actually tried that).
Dynamic (thread in process) places seem to have issues when there are many instances, so for lots of cores it is better to use distributed (parallel process) places. Paulo Matos's Loci package makes using process places much easier [and it also works on Windows if that matters].
https://pkgs.racket-lang.org/package/loci
[1]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/988f052c8170da661c49dd51d1f33d500a871031/frameworks/Racket/racket/scripts/run#L15-L19
George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/b763ea64-6319-b162-747b-825cf1cabcb9%40comcast.net.
