I finally got a very simple, "hello world", Racket web app up and running,
and I'm very encouraged with the performance. I just started a single
Racket instance and proxy to it from nginx. I have it running on an AWS EC2
instance, and running the Apache Benchmark (ab) utility on my laptop as
Very interesting. I'll check out your project - thanks for mentioning it.
On Monday, November 26, 2018 at 4:42:15 AM UTC-5, Jérôme Martin wrote:
>
> Just so you know, I started some months ago a Racket project that would
> help monitor different Racket web servers and load-balance them, using
>
The current Ruby/Rails app will max out at least one core at times now. I
realize Racket should be faster, but I expect I'll still need more than a
single core for the app as the volume will be going up significantly in
January, and as you mentioned, there are some other benefits to a
Just so you know, I started some months ago a Racket project that would
help monitor different Racket web servers and load-balance them, using
systemd-nspawn as a native container system, and an optional
nginx server to load balance everything, serve static content and cache
dynamic one.
It's
I just want to point out the possibility that your Racket web app
might not be CPU-bound. Some "generic" web sites are IO-bound. Blocked
on IO for the HTTP requests and responses. Blocked on IO talking to a
database server like Postgres.
In cases like that, you might not need more than one
I probably wasn't very clear about what's going on with Unicorn when I
deploy a new version of the app. It's actually quite simple, and doesn't
require loading new code on the fly. Here's what I do:
1) I update the app server code via: git pull (this doesn't affect the
running processes due
Hi Brian,
On 23 Nov 2018, at 21:46, Brian Adkins wrote:
I'm porting a web application from Ruby/Rails to Racket, and I'd like
something to manage the Racket server processes.
In the Ruby world, I'm currently using Unicorn (
https://en.wikipedia.org/wiki/Unicorn_(web_server) ) prior to that I
I'm glad to hear about the Racket web server's reliability! I'm still
working through the high level architecture, but it seems like one Racket
instance per core make sense to maximize cpu utilization, and then I may
spin up a thread per request w/in each process to maximize memory
I'm not sure if this was clear from what I said earlier, but I use the
Racket web server without anything in front of it. In fact, Racket does SSL
termination and serves as a proxy for non-Racket services. We have been
completely satisfied with its performance and reliability.
-Philip
On Sat,
In my experience a Racket web server will just stubbornly continue to
work for months at a time, if you let it.
(Reminds me of the aviation joke. In the future, cockpits will have
just one human pilot and a dog. The dog is there to bite the human if
they try to turn off the autopilot.)
I have a
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'
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
I'm porting a web application from Ruby/Rails to Racket, and I'd like
something to manage the Racket server processes.
In the Ruby world, I'm currently using Unicorn (
https://en.wikipedia.org/wiki/Unicorn_(web_server) ) prior to that I used
Nginx Passenger (
13 matches
Mail list logo
