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.

Reply via email to