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. 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. [1]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/988f052c8170da661c49dd51d1f33d500a871031/frameworks/Racket/racket/scripts/run#L15-L19 -- 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/m27dwgiuwo.fsf%40192.168.0.142.
