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
<mailto: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.
