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 to [email protected]. For more options, visit https://groups.google.com/d/optout.
