On Monday, June 8, 2020 at 6:11:37 PM UTC+8, Yury Bulka wrote:
> Wow, from 695 requests per second to 49,516 is a huge improvement! 
> Since we were comparing to django previously, it's now much closer with 
> django (which does 78,132 rps.) 

I know very little about web development, so these may be some stupid 
questions, but I am very curious.

I am looking at 
and even with 78k requests/second, Django is at the bottom of that list 
(position 98 out of 104).  In fact, most of the web frameworks that I can 
recognize are at the bottom of this list, and their score is also very 
modest, compared to the frameworks at the top.  The highest framework that 
I can recognize in that list is "flask" and its performance is a mere 4.8% 
of the top one.

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.

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?



> Django also does run multiple worker processes (3 per cpu): 
> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Python/django/gunicorn_conf.py#L8
> The other tests are also doing much better. 
> So do I undestand correctly that the factors that contribute to the 
> improvement are: 
> 1. running multiple worker processes behind nginx 
> 2. adding content-length to all responses 
> 3. using CS variant of Racket 
> 4. using Racket 7.7 
> 5. tuning nginx config (enabling http 1.1 especially) 
> I'm curious what was the individual contribution of these factors. In 
> the PR regarding #5 you already stated that it gives a 4-5x improvement. 
> #1 and #5 are the things one would normally do anyway in a production 
> setup I guess. As is #4 most likely. 
> #2 is something that seems to require manual work in the client code, 
> but maybe that can be made easier on web-server-lib side somehow. 
> Curious how much do #3 contribute. 
> Big thanks again for everyone investing time in investigating this. 
> -- 
> Yury Bulka 
> https://mamot.fr/@setthemfree 
> #NotOnFacebook <https://mamot.fr/@setthemfree#NotOnFacebook> 
> Bogdan Popa <bog...@defn.io <javascript:>> writes: 
> > Small update on this: I've updated the benchmarks to run multiple Racket 
> > processes with an Nginx load balancer in front.  After some tuning[1], 
> here 
> > is what the results look like on my 12 core AMD Ryzen 9 3900 server: 
> > 
> > 
> https://www.techempower.com/benchmarks/#section=test&shareid=669bfab7-9242-4c26-8921-a4fe9ccd8530&hw=ph&test=composite&a=2
> > 
> > 50k/s is a respectable number for the plaintext benchmark IMO and we 
> > could get it to go higher if we could ditch Nginx or spend more time 
> > improving the server's internals, as Sam suggested. 
> > 
> > The `racket-perf' benchmark is for a branch[2] that I have where I've 
> made 
> > some small improvements to the server's internals. 
> > 
> > [0]: https://github.com/TechEmpower/FrameworkBenchmarks/pull/5727 
> > [1]: https://github.com/TechEmpower/FrameworkBenchmarks/pull/5737 
> > [2]: https://github.com/racket/web-server/pull/94 

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 

Reply via email to