On Thursday, June 4, 2020 at 1:45:30 AM UTC-4, Neil Van Dyke wrote:
> I'm now leading engineering at a startup with an established Python & 
> Flask infrastructure, and happen to urgently need an additional dynamic 
> Web&database service backend that's separate from the rest of our 
> infrastructure...  While I could do it in Flask, I was thinking that 
> this might also be an opportunity for a Scheme (Racket) pilot project 
> for the company,[1] looking ahead to tech stack selection for some much 
> larger infrastructure expected next year (if the startup survives the 
> virus). 
> The problem with this as a pilot project is that this server will see 
> only very light duty, and therefore not good for evaluating real world 
> viability for the expected future high-traffic needs. 
> So I was wondering whether anyone (other than HN, and the bespoke 
> framework stuff I worked on atop the `scgi` package) is currently using 
> Racket for dynamic HTTP/S backend in a *high traffic* setup? And if you 
> are handling high traffic, what kinds of performance are you seeing 
> (e.g., request volume, simultaneous requests, latency, GC 
> characteristics), and how have you built it (e.g., which HTTP libraries, 
> what kind of server infrastructure)? 

I have two Racket web apps in production, but I wouldn't say they're high 
traffic. I'm also curious about any high volume use of Racket.

As part of my due diligence in choosing Racket, after more a couple decades 
of web development in Java, .NET and Ruby/Rails, I satisfied myself that 
the performance exceeded Ruby/Rails significantly by running a number of 
benchmarks on the typical workloads my apps experience. Using one Racket 
process per core with a thread per request within each process makes *much* 
better use of the CPU for a given amount of RAM than a typical Rails setup 

The current architecture is very simple - I use an nginx web server as both 
a load balancer and to handle SSL. This delegates to two Racket processes 
(managed by systemd) on a two core server. Postgres runs on a separate AWS 
RDS server. Moving to a "real" load balancer in front of multiple EC2 
instances would be trivial, and would handle a tremendous amount of traffic.

I mentioned in another thread that an Apache Bench benchmark showed 350 
requests per second on an AWS EC2 t3.small server w/ both the Apache Bench 
and web app running on the same server. A t3.small is very limited, so ~ 
350 req/s (i.e. roughly a billion req/month) seems like very reasonable 

As to libraries, etc., I'm using the Axio Web Framework. Unfortunately, 
nothing is yet available publicly since I'm still developing it. The second 
web app allowed me to make significant enhancements, and a third planned 
web app will probably provide a few more unique demands to round out the 
functionality enough to publish a 0.1 version.

An important caveat is that I'm *not* currently developing with a 
complicated ORM setup, and that's an area where Rails has made many 
refinements in terms of both usage & caching. The initial release of Axio 
will *not* contain an ORM, but it will have a number of niceties for 
interacting with the database. After a decade of Rails usage, I was quite 
surprised at how little I was impacted by working more directly with SQL.


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.
To view this discussion on the web visit 

Reply via email to