Re: [racket-users] Re: current racket dynamic web performance in production?

2020-06-07 Thread 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 

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

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

[racket-users] Re: current racket dynamic web performance in production?

2020-06-04 Thread 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 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 view this discussion on the web visit