dbohdan wrote on 09/09/2017 02:40 PM:
When I limit the memory usage in racket-custom to the total RAM on the
VPS minus what the OS uses (through custodian-limit-memory) Racket
quits with an out of memory error at the point when it would be killed
by the OS. racket-scgi seems to behave the same, though I didn't look
at the memory usage split between Racket and nginx when I tested it.
Especially for small devices pushed to the limit, like this benchmark is
approximating... We can manage process size in Racket so that it doesn't
get OOM-killed or crash on a failed allocation at a bad time in the
Racket VM. This can be via smaller limits within Racket, the timing of
GC, application code being savvy about allocations, maybe something with
Racket Places, or being creative with some of the properties of Linux
host processes.
For the racket-scgi + nginx setup, if nginx can't quickly be tuned to not be a
problem itself, there are HTTP servers targeting smaller devices, like what
OpenWrt uses for its admin interface.
But do they support SCGI?
I used Lighttpd several years ago, which supports SCGI, though I don't
know the current resource footprint. (I used Lighthttpd as a tiny Web
server within each cloned Windows image in an research virtualization
experimental testbed, and it worked fine for that light purpose.)
For Racket Web serving on *small* devices, I'd want to try a
lightweight, hand-optimized HTTP server in pure Racket, not put
Nginx/Apache/etc. and SCGI/FastCGI in front of it. Nginx and Apache
might not be carrying their own weight on a small device, for the kinds
of applications I'd expect on a small device (unless you need to
implement an organization's complex, custom SSO authentication method,
and there's an Apache module). Other reasons for a fronting server
don't usually apply to small devices: serving high-volume static content
from the same host/port, using off-the-shelf load balancing, and
possibly an off-the-shelf attempt at enduring DoS. Racket's I/O and
language are sophisticated enough that you can do some clever
performance things, and maybe that's how you make a particular
application on a particular device viable.
Your benchmarking work has been good for getting some interest and
discussion going. Racket made a good showing in some of the benchmarks
already, but these aren't going to show off the best that can be done in
Racket, since a lot of space is yet to be explored. Two ways to move
forward:
(1) work on individual real-world applications, incidentally advancing
Racket's capabilities in ways that transfer to some other applications; and
(2) a priori generalized effort like "we want to make a Racket solution
for many simultaneous clients of trivial/nontrivial Web services on
small devices, that will usually do what people need, out of the box",
and/or similar effort for large scale Web services/applications.
The Racket community's skill base is capable of both #1 and #2 above.
But, for funding reasons (I suspect hard to find a research angle on #2,
unless it involves something novel and big with the Racket backend), I
suspect that an organic #1 is more likely than #2. A possible exception
in favor of #2 is if someone has the hobby time available to go to war
on pure benchmarks, without a motivating/guiding application (and I
could certainly appreciate the appeal of that, when one has the time).
--
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.
For more options, visit https://groups.google.com/d/optout.
