It wasn't confidence inspiring.
EDIT: It's fixed in 6.8, which fills me with some hope.
Which is good.
It handled everything fairly well, for a short-lived (month or two), API server that received several hundred thousand requests a second. (A stand-in server to handle some updating for some hardware in the field. Our normal server failed catastrophically, and took out the entire rack, which included the backup... So we needed something up quick, whilst we rebuilt the backup and redeployed the front-facing servers.)
It was fast to work with, but that's sort of a given with any Lisp, even though we had some ties between web, typed, and lazy Racket.
The documentation wasn't awesome. There's enough to get you started, but at the time, there wasn't a lot more.
But, Racket is fairly predictable in how functions are exposed, and how they should work. (As well as having a REPL to rapidly prototype).
I lifted out the MIME functions and some of the threading functions. Probably the request constructors as well.
It was also on a Heroku scaling dyno.
In my testing, the inbuilt web server is decent, but starts becoming hit and miss around 10,000 - 25,000 requests/sec, depending on hardware.
More than enough for hobby sites, but not quite enough for heavier enterprise applications.
What you do with each request can have huge impacts, a colleague tried to lazily render templates, so follow pre-rendering best practices.
What are you comparing it to here? Something fast written in java or go? I could understand racket being slower than that, but surely it'd perform faster than the likes of flask or sinatra.
Also, rewriting it in Go helped me understand that my brain is wired for imperative languages, not functional: writing algorithms felt so much easier and more natural in Go. Nevertheless, learning Racket was fun!