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:

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.


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 view this discussion on the web visit

Reply via email to