Welcome!

John Carmack wrote on 03/18/2015 02:59 PM:
I would be interested in hearing any guidance for high performance servers 
written in Racket.  GC delays in the tens of milliseconds will be problematic 
for at least part of this application, but I could split that part off into a 
separate server and still leave the other part in Racket if necessary.  The 
main benefit is currently development productivity, so obnoxious 
micro-architectural optimizations aren't useful, but broad strategic guidelines 
would be appreciated.

Architecture-wise, for dynamic HTTP serving, I've started to play with different ways to avoid GC delays, as well as reducing general contention serving simultaneous requests. The direction I'm heading is scheduling requests among multiple Linux processes each running Racket, or Racket "Places" (which can at least distribute across cores). The worker processes might be short-lived (in which case maybe GC could be disabled altogether). The front-end might be in Racket, or in C, or use some Linux kernel facility. It might turn out to just be an off-the-shelf load-balancing problem, but I'd like to see whether there are any wins from doing it in Racket (e.g., awareness of GC info, sharing information within Racket space), as well as keeping it "lightweight" (in the sense that anyone could get it by simply loading a library and hitting the Run button on DrRacket, without setting up any infrastructure). No results to report yet.

Micro-optimization-wise, I like doing I/O-intensive stuff in C-like ways, such as managing ring buffers in Racket `bytes` with routines like `read-bytes-avail!` (and generally reducing copying and allocations), and with `sync/timeout`.

BTW, agreed on the temptation to use sexps over JSON (if the transport is not something that arbitrary JS programmers would be working with directly). For the trivial embedded Scheme, a good starting point is R5RS, and then strip out any parts that hurt performance in your particular implementation approach (e.g., first-class continuations, numeric tower beyond native integer and float).

Neil V.

____________________
 Racket Users list:
 http://lists.racket-lang.org/users

Reply via email to