On 11/23/2018 4:38 PM, Philip McGrath wrote:
I'm not familiar with Ruby, so this is just some general information.
The Racket web server already supports concurrency with its built-in
green threads, so handling one request won't block the concurrent
handling of another. (Not all languages' built-in web servers do this;
I don't know about Ruby in particular).
There isn't built-in support for parallelism, i.e. for taking
advantage of multiple processor cores. This isn't built in, and I
don't personally need this (my server only has two cores, and it runs
a database and other processes in addition to Racket). However, it is
probably possible to recreate the architecture you describe.
Essentially you would be running multiple instances of your
application behind a load-balancer. If you want to use nginx as a load
balancer, that's out of the equation; implementing a load-balancer in
Racket would certainly be possible but probably more work.
Extra-linguistically, you could just create a few systemd services or
similar to run several totally separate Racket instances. Within
Racket, you would want to build on "places." You can have N worker
places running N instances of your application on N OS-level threads,
plus a master place to control them. A mechanism for gracefully
stopping the Racket web server is built in (see serve/launch/wait
Reloading isn't built in, but I've heard good things about the
(https://pkgs.racket-lang.org/package/reloadable), which should let
you implement it if needed.
While I only run one instance of our application, I do use places to
redirect HTTP to HTTPS.
One caveat is that all of this assumes that, if you are using
continuations at all, you are using serializable continuations with
`#lang web-server`. Making places work well with native continuations
would probably be a lot of work, and it would probably be better to
build that functionality into the Racket web server than to try to
fake it as a client.
Just a comment:
Multiple (identical) server instances running on the same machine can
listen for connections on the same network port - an incoming client
call will be connected to only one of them. You only need to use
different ports when services are not interchangeable [i.e. it matters
which one you are talking to].
Process parallelism, in effect, can give you automatic connection load
balancing on a single machine. Using a separate load balancer in front
technically is overkill for such situations, but it is a good design if
you want to preserve the option to relocate your services to different
You received this message because you are subscribed to the Google Groups "Racket
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.