[racket] Serving static content

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 <neil at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20150320/a072cdc0/attachment.html>