<div dir="ltr"><div>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.<br><br></div>I would generally use something like nginx for static files and Racket for servlets. I wouldn't use Apache at all.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 20, 2015 at 10:16 AM, Neil Van Dyke <span dir="ltr"><<a href="mailto:neil@neilvandyke.org" target="_blank">neil@neilvandyke.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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).<br>
<br>
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+<u></u>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.)<br>
<br>
[*] Witness yesterday's yet-another-Debian-security-<u></u>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.<br>
<br>
Neil V.<div class="HOEnZb"><div class="h5"><br>
<br>
____________________<br>
 Racket Users list:<br>
 <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/<u></u>users</a><br>
</div></div></blockquote></div><br></div>