I'm pretty sure Racket is not much less scalable than Apache, which is notoriously poor at scaling due to its fork-pool approach. I actually don't know about it, but I see no architectural reason why the Racket HTTP server would be much slower than, say, nginx - Racket threads after all are scheduled in userspace.
I would generally use something like nginx for static files and Racket for servlets. I wouldn't use Apache at all. On Fri, Mar 20, 2015 at 10:16 AM, Neil Van Dyke <n...@neilvandyke.org> wrote: > What Jay said. If you want to keep things simpler, and are only going to > have a few simultaneous requests at a time, you can have Racket serve all > the HTTP directly. But I almost always decide an obvious first thing to do > is to push off static file serving to Apache (or nginx, or lighttpd), > before I even test performance. You can feed to Racket process using HTTP > proxying or my old SCGI library. Separating static from dynamic also makes > sense for CDN reasons. > > Also, besides possible performance reasons, there's a good chance an > application is going to want to use HTTPS at some point. The SSL > implementations tend to be buggy[*], and you probably don't want native > library code in the same process space as your Racket VM unnecessarily. > Imagine an intermittent Linux process crash failure in your deployed > system, and how glorious it would be for your debugging if it were Apache > crashing rather than Racket. I'm happy to report that Racket doesn't crash > on my servers (except for, years ago, OOM due to some memory-voracious > application code written by a non-CS person). > > Also, if you're doing applications deployed as intranet ones for different > organizations, sometimes you'll need to do unusual SSO authentication, and > it's nice when you can just use the same Apache module that they use. > (I've implemented at least half a dozen different authentication protocols > in pure Racket, and Racket is definitely up to the software part of the > problem, but you probably don't want to be in the business of > understanding+implementing+supporting some other vendor's or IT group's > unique SSO setup. I'd have to do that even more, if I couldn't dump a lot > of the more standard SSO setups on Apache modules.) > > [*] Witness yesterday's yet-another-Debian-security-update of OpenSSL, > with another 6 CVEs, because very few people write perfect code in C, and > SSL-related protocols tend to be hairy. If some ambitious student wants a > fun summer project, try implementing an SSL stack in pure Racket. > > Neil V. > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users >
____________________ Racket Users list: http://lists.racket-lang.org/users
