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 
follows reported 300 requests per second (38 concurrent requests, 1000 
requests total):

ab -c 38 -n 1000 http://hello-app

Granted, the "hello world" app is doing the bare minimum (no database 
connection, minimal processing, etc., but it is logging requests), but the 
fact that I'm getting 300 req/sec including proxying through nginx with one 
single-threaded Racket process (& zero time spent tuning) is great news! Of 
course, over a decade with Ruby may have lowered my performance bar 
somewhat ;)

I can't wait to get a more representative test running.

On Monday, November 26, 2018 at 10:38:23 AM UTC-5, Brian Adkins wrote:
> 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 racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to