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
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:
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 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
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].
You received this message because you are subscribed to the Google Groups "Racket
To unsubscribe from this group and stop receiving emails from it, send an email
To view this discussion on the web visit