current racket dynamic web performance in production?

[Neil Van Dyke]

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)?


[1] A similar urgent new server in Racket has happened before.
https://lists.racket-lang.org/users/archive/2009-October/036244.html

[Brian Adkins]

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 does.

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 performance.

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.

Brian

[Neil Van Dyke]

Thanks for the info, Brian.

I'm getting the impression that Scheme/Racket Web production serving is
sorta in same place it has been for the last couple decades: such that a
really good and prolific developer can make a system work well in
production, iff they can put in a lot of work beyond off-the-shelf
components.

When deciding whether to to go Scheme/Racket, we consider the pros --
e.g., the linguistic power of Scheme, the ability to attract talent due
to using a fringe language that people like or want to learn -- and
weigh them against the greater amount of bespoke work, the necessity to
then have non-commodity developers who are up to doing that well, and
the greater risks/unknowns that might not be solved by throwing a larger
AWS bill at a problem.[1]

For the server project I'll develop this week, it doesn't actually take
advantage of Scheme, and the project also won't function as a good pilot
project for scalability, so I'll probably just use Python&Flask this
time.  I'll keep Scheme/Racket in mind for this, as a known-quantity
backup plan, but probably Scheme/Racket will have to wait until later
this year for a better opportunity to shine.

There is a GUI frontend project coming up that might be a better
opportunity for Racket to be useful in production.  It would be 2nd
generation replacement of a deployed specialized appliance frontend,
which currently is done in JS in Chrome (no, not the horrifying
touchscreen Web browser spaceship consoles we heard about the other day
:), and some special hardware device interfacing.  I've prototyped
replacing it with with Python Kivy,[2] but I happen to know that
Racket's GUI library would be easier to use for this purpose, and result
in more-solid UI operation.

After that, the next opportunity is probably 2nd generation of the
entire server infrastructure, and we'll have to see what our needs and
resources are like at that time.  We'll probably have that 2nd-gen work
in mind if/when we do more engineering hiring later, and, in any case,
I'd like to be able to hire the kinds of developers who are up to the
challenges of doing bespoke work that works.[3]


[1] Though I think the risks/unknowns of a less-popular stack aren't
what many developers are thinking when they flock to the most popular
tools of the moment because a FAANG does it.  What tools&practices work
for a FAANG, with massive infrastructure, massive staffing, and the
practice of routinely shutting down large numbers of projects (and
making many multi-billion dollar acquisitions of competitors, when the
FAANG still fails to outperform upstart competitors with their
project)... aren't necessarily the tools&practices a startup should use,
with their handful of people who have to wear many hats, and actually
have individual contributors understand the entire system, in order to
make it work well enough and to troubleshoot problems rapidly, despite
very limited resources.

[2] As I was evaluating GUI toolkits, there's ongoing
bitrotting/abandonware of the desktop GUI space, as development flocked
to adtech/VC-driven Web sites and smartphone apps, and people started
favoring embedded massive browser engines (which have pros and cons). 
And it looks to be self-perpetuating, because the non-Web GUI toolkits
get less attention.  Kivy was one of the few current non-abandoned
toolkits.  Racket's cross-platform GUI toolkit remains supported for
solid Win95-era desktop GUIs, and is currently looking better than
Python and JS-framework-in-WebKit options, for the particular kind of
(non-consumer) touchscreen appliance console we'll need to do. (For
slick consumer-facing UIs, I'm currently going through the rapid mood
swings experience of the SwiftUI DSL and related iOS stack. :)

[3] And I've long believed that using one of the less-popular but
beloved platforms -- like Scheme/Racket, Common Lisp, Haskell, OCaml,
Erlang, or Rust -- is a great way to find and attract some of the best
developers.  FAANGs can say to some of those developers, "we'll pay you
more money, and everyone else who aspires to make FAANG money will be
impressed when they see us on your resume", but the toolset you get to
use can be one of the significant selling points of a competing value
proposition.