4 ms·

I really, badly wanted to use racket for server side programming. But last time I tried, in december, I discovered there was a typo in the contract of the struc

I really, badly wanted to use racket for server side programming. But last time I tried, in december, I discovered there was a typo in the contract of the struct used for http responses. It wasn't confidence inspiring. EDIT: It's fixed in 6.8, which fills me with some hope.

shakna 10y ago
I've run an async Racket web server on Heroku, and it was entirely unexciting. 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).
- 147 10y ago
  Were you using the built in web server? I've been wondering about its performance in real world loads.
  - shakna 10y ago
    Only partially. 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.
    - lacampbell 10y ago
      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 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.
      - shakna 10y ago
        It's about the same as what I get out of most things. Usually, this just ends up being the C10k problem, which you need some not-so-nice code to work around.
- dmux 10y ago
  The documentation is my biggest frustration with Racket. Trying to grok how to use something as simple as their HTTP module proved difficult. It's great documentation, but seems to be aimed at a more academic level than pragmatic.
dchest 10y ago
As a data point, this little Racket server — https://github.com/coding-robots/iwl https://github.com/coding-robots/iwl — served millions of requests from late 2010 until early 2016 (when I switched to Go) without any issues first on a smallest Rackspace Cloud instance, then on a smallest DigitalOcean instance.
- lacampbell 10y ago
  Thanks for the info. Curious - why the re-write if racket performed well enough?
  - dchest 10y ago
    For no practical reason — actually, for the same reason I rewrote in from the original Python version: I just fell in love with the language (first Racket, then Go). 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!

shakna 10y ago

I've run an async Racket web server on Heroku, and it was entirely unexciting. 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).

147 10y ago
Were you using the built in web server? I've been wondering about its performance in real world loads.
- shakna 10y ago
  Only partially. 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.
  - lacampbell 10y ago
    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 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.
    - shakna 10y ago
      It's about the same as what I get out of most things. Usually, this just ends up being the C10k problem, which you need some not-so-nice code to work around.
dmux 10y ago
The documentation is my biggest frustration with Racket. Trying to grok how to use something as simple as their HTTP module proved difficult. It's great documentation, but seems to be aimed at a more academic level than pragmatic.

dchest 10y ago

As a data point, this little Racket server — https://github.com/coding-robots/iwl https://github.com/coding-robots/iwl — served millions of requests from late 2010 until early 2016 (when I switched to Go) without any issues first on a smallest Rackspace Cloud instance, then on a smallest DigitalOcean instance.

lacampbell 10y ago
Thanks for the info. Curious - why the re-write if racket performed well enough?
- dchest 10y ago
  For no practical reason — actually, for the same reason I rewrote in from the original Python version: I just fell in love with the language (first Racket, then Go). 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!