I use the Web server in a few different places in production. The ones that get the most traffic are probably things like DrDr and the package server. I think Marc's post has more useful information than I could probably offer.
Jay On Sun, Jan 24, 2016 at 2:16 PM, David Storrs <david.sto...@gmail.com> wrote: > Thank you so much, Marc. I really appreciate the detailed answer and the > numbers. I'll feel much better about using Racket for production now. > > Dave > > On Sun, Jan 24, 2016 at 10:27 AM, Marc Burns <m4bu...@uwaterloo.ca> wrote: >> >> Hi David, >> >> I use the Racket web server in production to serve authentication and >> misc. requests that don't play nicely with our main web framework. >> >> There's been no difficulty integrating with outside systems. We use nginx >> in front of Racket for SSL termination and some light request processing; >> nothing unusual was required. Stephen Chang's redis client library works >> well. There were once some issues with file descriptor cleanup in the web >> server, but I haven't encountered any leaks for a couple of years. >> >> Load testing: >> >> ---- >> m4burns@m4burns:~$ ab -n 10000 -c 10 http://192.168.1.1:12345/auth/whoami >> This is ApacheBench, Version 2.3 <$Revision: 1604373 $> >> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ >> Licensed to The Apache Software Foundation, http://www.apache.org/ >> >> Benchmarking 192.168.1.1 (be patient) >> Completed 1000 requests >> Completed 2000 requests >> Completed 3000 requests >> Completed 4000 requests >> Completed 5000 requests >> Completed 6000 requests >> Completed 7000 requests >> Completed 8000 requests >> Completed 9000 requests >> Completed 10000 requests >> Finished 10000 requests >> >> >> Server Software: Racket >> Server Hostname: 192.168.1.1 >> Server Port: 12345 >> >> Document Path: /auth/whoami >> Document Length: 28 bytes >> >> Concurrency Level: 10 >> Time taken for tests: 7.261 seconds >> Complete requests: 10000 >> Failed requests: 0 >> Non-2xx responses: 10000 >> Total transferred: 2270000 bytes >> HTML transferred: 280000 bytes >> Requests per second: 1377.15 [#/sec] (mean) >> Time per request: 7.261 [ms] (mean) >> Time per request: 0.726 [ms] (mean, across all concurrent requests) >> Transfer rate: 305.29 [Kbytes/sec] received >> >> Connection Times (ms) >> min mean[+/-sd] median max >> Connect: 0 0 0.0 0 0 >> Processing: 1 7 8.3 6 194 >> Waiting: 1 6 7.7 5 193 >> Total: 1 7 8.3 6 194 >> >> Percentage of the requests served within a certain time (ms) >> 50% 6 >> 66% 7 >> 75% 7 >> 80% 8 >> 90% 10 >> 95% 15 >> 98% 18 >> 99% 20 >> 100% 194 (longest request) >> ---- >> >> So, it does just fine under heavy load. This service has been left running >> for a couple months at a time and nothing weird has happened. >> >> Regarding deployment speed, Typed Racket is a bit slow to compile right >> now. You can get around this by structuring your program (possibly using >> units) to allow greater build parallelism. Untyped Racket builds quickly. >> >> Unless you go out of your way to implement reloadable components (possibly >> using https://github.com/tonyg/racket-reloadable ), updating the system will >> require bouncing the server. If your server doesn't maintain internal state >> between requests, you can bounce it without any interruption. For example, >> you could set up nginx to use a backup upstream server on an alternate port. >> When you want to upgrade, start the new server on the alternate port before >> you kill the old one. After the old one has died, you can move back to the >> primary port. >> >> The continuation-based framework for managing state is very convenient. If >> you choose to keep state on the server, some care must be taken to limit >> memory use and properly evict unneeded continuations. Keeping state on the >> client works brilliantly. >> >> Using the Racket webserver has always been a breeze for me. It's easy to >> do stuff that requires mucking with HTTP and it's easy to build complete, >> reliable apps. This kind of flexibility really makes my day. >> >> Good luck in your endeavor. >> >> Cheers, >> Marc Burns >> >> >> On 2016-01-23 5:23 PM, David Storrs wrote: >> >> Is anyone here using the Racket web server in production? If so, what's >> your experience with it? Specifically: >> >> Have you had any difficulty integrating it with outside systems? (e.g. >> Varnish, Redis, load balancer ooling, etc) Most of this I wouldn't expect >> to be an issue, but I figured I'd ask for unknown unknowns. >> >> What sort of load testing have you done and how has it held up? >> >> What has your general experience been as regards deployment speed, etc? >> >> Can you update the system on the fly without interrupting current users, >> or does it require bouncing the server? >> >> I'm doing my due diligence on a tech startup concept and would like to use >> Racket, but I want to make sure the tools are appropriate. For reference, >> the concept is crowdfunding for artists with a focus on campaign growth >> instead of enablement. >> >> Dave >> -- >> 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. >> >> > > -- > 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. -- Jay McCarthy Associate Professor PLT @ CS @ UMass Lowell http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33 -- 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.
