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 <gneun...@comcast.net> 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-users+unsubscr...@googlegroups.com. > 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/CAK%3DHD%2BauHeC6veH-867PuiihSbYmZB2hKyx5ZnBH%2B-1sXUKwxA%40mail.gmail.com.
