I may look into this in more detail later, but I ran a simple benchmark 
comparison on my modest AWS EC2 server (ApacheBench can behave poorly on 
MacOS).

1) I ran ApacheBench w/ 6 processes to fetch a simple "hello world" static 
html file using only nginx. I got roughly 650 requests per second.

2) I then ran ApacheBench w/ 6 processes against one of my Racket web apps 
using a monitoring endpoint that does a simple db query to determine the 
health of the server, so this went from nginx (acting as a load balancer 
and https handler) to the Racket processes via proxy_pass (only 2 running 
in parallel) which exercises my custom dispatching and a simple postgres 
query. No continuations and completely stateless. I got roughly 350 
requests per second.

At first glance, that doesn't appear to be that much overhead when 
comparing the two. In fact, I would've expected the very small static html 
request to be significantly more than double the req/sec of the Racket app 
db request.

I developed Rails apps for over a decade, and I know my Racket web apps are 
significantly faster in similar "database backed web apps" context.

I believe there is something wrong with those benchmarks at the moment.

Brian

On Monday, June 1, 2020 at 3:40:52 PM UTC-4, Sam Tobin-Hochstadt wrote:
>
> I'm skeptical both of the DB explanation and the multi-core 
> explanation. As you say, the difference between something like Django 
> and Racket is much too large to be explained by that. For example, on 
> the "plaintext" benchmark, Racket serves about 700 req/sec (I get 
> similar results on my machine). Many of the benchmarks in languages 
> like Python and Ruby do more than 1000x better, which means that even 
> if we had perfect speedup on 32 cores, we'd be nowhere close. 
> Additionally, the "plaintext" benchmark doesn't touch the DB at all. I 
> tried commenting out all of the DB code entirely, and it did not 
> change the results. 
>
> My guess is that the web server is just doing a lot of per-response 
> work that would need to be optimized. 
>
> Sam 
>
> On Mon, Jun 1, 2020 at 2:12 PM George Neuner <gneu...@comcast.net 
> <javascript:>> wrote: 
> > 
> > 
> > On 6/1/2020 1:40 PM, Bogdan Popa wrote: 
> > > I replied earlier today off of my Phone, but, for whatever reason 
> > > (caught in the moderation queue?), it's not showing up in this thread. 
> > > 
> > > Here's what it said: 
> > > 
> > >     The reason for poor performance relative to the other 
> > >     langs/frameworks is that there is currently no easy way to take 
> > >     advantage of multiple cores using the web framework so that's 
> being 
> > >     benchmarked is single-core performance. 
> > > 
> > >     This is mainly a problem for benchmarks such as this, but not 
> really 
> > >     an issue in the real world where you'd just run multiple processes 
> > >     with a load balancer in front. 
> > 
> > Single core [by itself] doesn't explain the enormous performance 
> > difference between Racket and Django. 
> > 
> > I haven't looked at the Django submission - Python's (in)comprehensions 
> > give me a headache.  But Python's DB pool is threaded, and Python's 
> > threads are core limited by the GIL in all the major implementations 
> > (excepting Jython). 
> > 
> > There are a few things Python can do faster than Racket, but the VAST 
> > difference in performance shown in the techempower tests isn't explained 
> > by them.  My suspicion is that the Racket application is making too many 
> > database connections and not relying enough on its open connection 
> > pool.  Hundreds of trivial requests can be served in the time it takes 
> > to spin up a new backend process. 
> > 
> > YMMV, 
> > 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...@googlegroups.com <javascript:>. 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/9236dcff-81df-1db8-c2ef-06b20e4690ec%40comcast.net.
>  
>
>

-- 
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/ce26a93b-e1f2-425a-abc9-be991ff0e4e4%40googlegroups.com.

Reply via email to