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 -- 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 https://groups.google.com/d/msgid/racket-users/088c4a80-93fb-41ec-b61a-a0d7a9b58531%40googlegroups.com.
