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 
multi-process architecture.

On Sunday, November 25, 2018 at 11:26:11 AM UTC-5, Greg Hendershott wrote:
> 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 process. (Indeed 
> you might even get away with running on a t2.micro instance, which 
> throttles horribly after a short CPU burst, because you never come 
> close to that threshold even under your maximum traffic loads.) 
> It's a real possibility you might want to measure/see, first. Of 
> course it depends on how much work your Racket web app does (itself, 
> not farmed out to DB or other out-of-process servers), as well as on 
> the traffic loads you expect. 
> Having two or more servers might be convenient for non-load reasons. 
> For updates (to let the old "drain" as you described, or blue/green 
> deploys, etc.).  Or for fail-over (although I'm not sure 2 procs on 
> same box is the way to go, if you even really need many 9s (many sites 
> really don't if we're being honest with ourselves)). 

You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to