Re: [racket-users] Using Racket server in production?

[Jay McCarthy]

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  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  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 1 -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 1 requests
>> Finished 1 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:  1
>> Failed requests:0
>> Non-2xx responses:  1
>> Total transferred:  227 bytes
>> HTML transferred:   28 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:00   0.0  0   0
>> Processing: 17   8.3  6 194
>> Waiting:16   7.7  5 193
>> Total:  17   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 req

Re: [racket-users] Using Racket server in production?

[David Storrs]

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  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 1 -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 1 requests
> Finished 1 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:  1
> Failed requests:0
> Non-2xx responses:  1
> Total transferred:  227 bytes
> HTML transferred:   28 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:00   0.0  0   0
> Processing: 17   8.3  6 194
> Waiting:16   7.7  5 193
> Total:  17   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 t

Re: [racket-users] Using Racket server in production?

[Marc Burns]

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 1 -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 1 requests
Finished 1 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:  1
Failed requests:0
Non-2xx responses:  1
Total transferred:  227 bytes
HTML transferred:   28 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:00   0.0  0   0
Processing: 17   8.3  6 194
Waiting:16   7.7  5 193
Total:  17   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 e