Faster than Django and Rails :slightly_smiling_face:
https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite
Racket could do better on this benchmark through improvements to the web server (those alone would probably get it at least in the “10%” group). At the same time, some of the comparisons aren’t necessarily apples-to-apples.
For the “fortunes” benchmark, the Racket app uses x-expressions to render the HTML, which means that it has to construct a tree of x-expressions on every request then render the whole tree to HTML. The cost of both of those things adds up over many requests and many of the frameworks that do better than Racket on that particular benchmark use templating frameworks that cache/precompute a large part of the resulting HTML. Of course, we also have something like that in Racket (via scribble, include-template), but I tend to prefer xexprs so that’s what I used.
For the “queries”/postgres benchmarks, nearly all of those languages use libpq under the hood, whereas the postgres driver for Racket is written in Racket. Additionally, some of the top frameworks on that benchmark use a fork of libq that supports pipelining.
So definitely take those benchmarks w/ a grain of salt. The Racket web server’s perf. is good enough for most apps.
Does the racket/db binding need optimization? Or is it just naturally going to be a bit slower?
It would be fun to write an optimized, pre-compiled xexpr->html pipeline using macros, but probably not actually worth it for real applications
What are the web server optimizations you’re thinking of?
> Does the racket/db binding need optimization? Or is it just naturally going to be a bit slower? It already does surprisingly well (compare the “multiple queries” results for Racket vs some of the other frameworks with high results on “plaintext”). I just assume libpq is going to win in most cases when called from languages where C interop is cheap.
> What are the web server optimizations you’re thinking of? I don’t have anything top of mind right now, I just remember that a couple of years ago when I last looked there was room to do better even after the optimizations I made then.
Re. db, I actually used it to live migrate between two Postgres databases (30TiB)… on something like three separate occasions so I consider it extremely solid :smile:
I looked at the benchmark, and one thing I noticed is that the worlds-ref/random function would probably benefit from changing from running the select-one-world query in a loop to using the following SQL: SELECT id, randomnumber FROM worlds WHERE id =ANY ($1::integer[]) and passing a list of ids.
Oh, I see, the rules forbid it. Well, they specifically forbid IN, but presumably they intended to forbid =ANY also.
Yeah, the point of that part of the benchmark is specifically to run multiple queries per request.
What makes a server fast? What makes the racket server faster than Django? Is it partly because Python is slower?
Thanks for the answers/discussion
> Faster than Django and Rails :slightly_smiling_face: But slower than flask and aiohttp (two other Python HTTP frameworks/libraries). :wink:
> What makes a server fast? What makes the racket server faster than Django? Is it partly because Python is slower? I think that’s very hard to tell without careful profiling.