Re: [racket-users] Racket Web servlet performance benchmarked and compared

2017-09-02 Thread Neil Van Dyke 

dbohdan wrote on 09/02/2017 03:12 PM:
I rather like the SCGI protocol. It's a pity that it isn't as widely 
supported as FastCGI, considering that it's much simpler to implement 
(second only to plain old CGI), but still has a performance profile 
similar to FastCGI's. 


I mostly implemented FastCGI in Racket at one point, but then I read 
about the FastCGI implementation in my target HTTP server having hard 
bugs, so I abandoned that.


I also think there are faster ways to serve HTTP from Racket, but I'd 
have to find funding to work through them.


And we have to keep in mind that, unlike benchmarks for LINPACK or 
standard transaction processing, the real-world applications of HTTP 
servers are messier.  And also, I don't think many people have been 
tuning for Web application benchmarks, unlike was once done for LINPACK 
and TP.  I think the Racket community has enough skill to make a 
respectable showing in a benchmark tuning war, or in general platform 
performance for real-world Web applications, but I'm not aware of any 
funding going into that right now.


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

Re: [racket-users] Racket Web servlet performance benchmarked and compared

2017-09-02 Thread dbohdan 
On Friday, September 1, 2017 at 8:19:19 PM UTC+3, dbohdan wrote:
> My exceptions were [...]

This, of course, should say "expectations".


On Friday, September 1, 2017 at 9:38:25 PM UTC+3, Neil Van Dyke wrote:
> Thank you very much for doing this work, D. Bohdan.

You're welcome! I had fun doing it.

> This performance of Racket SCGI+nginx relative to the others you tested
is surprising to me, since I made the Racket `scgi` package for
particular non-performance requirements, and performance was really
secondary.

Thanks for making the 'scgi package. I rather like the SCGI protocol. It's a 
pity that it isn't as widely supported as FastCGI, considering that it's much 
simpler to implement (second only to plain old CGI), but still has a 
performance profile similar to FastCGI's.

> Not to look a gift horse in the mouth, [...]

No worries. The horse is given very much with that in mind. :-) To address your 
specific concerns:

> errors can cause good performance numbers. Sometimes I used
> JMeter instead of `ab` to rule out that cause of bad numbers in
> performance testing (as well as to implement some testing).  

I think the SCGI benchmark works correctly because of the data sizes that 
ApacheBench reports. For example, here is the request data from one run:

> Complete requests:  178572
> Failed requests:0
> Total transferred:  755002416 bytes
> HTML transferred:   733038060 bytes

733038060 / 178572 = 4105, which is exactly the size of the text message the 
application serves. The same is true of other data I've examined so far (5 
runs). To help detect errors, the benchmark is also programmed to abort if the 
first request to an application doesn't serve exactly the right text (see 
`run-when-ready.sh`) or if ApacheBench sees enough of nginx's status 502 pages, 
which are served when the SCGI server doesn't respond correctly or at all.

I'll look into using JMeter in addition to ApacheBench.

> the OS pushing into swap

Good point. I thought I'd already disabled the containers' access to swap, but 
apparently it didn't work because of a thing with cgroups. The "benchmarked" 
container still must have used swap, because it began to run out of memory for 
some applications when I disabled the swap on the VM itself. I've increased 
"benchmarked's" memory quota to 768 MiB and added a recommendation to disable 
the swap system-wide in README.md.

> sporadic network latency (though looks like you might've controlled for
that one)

The application and the load generator communicate through a virtual network 
between two Docker containers on the same host, so this should not be an issue.

> some other OS/hardware/network burp outside of your Racket
process(es).

Such burps are possible, and even likely, because I run the VM on a machine I 
use for other tasks. I try to ensure no taxing tasks run alongside the 
benchmark and mitigate the inevitable CPU spikes by simply benchmarking every 
application for longer (three minutes by default).

On Friday, September 1, 2017 at 9:51:13 PM UTC+3, Neil Van Dyke wrote:
> `#:scgi-max-allow-wait

Thanks for the suggestion. This turned out to be the key to SCGI performance. 
Increasing #:scgi-max-allow-wait from 1 to 4 (default), 16, 64, 256 gives a 
moderate increase in throughput (from ~2350 req/s to ~2900 req/s), but 
*decreases* the maximum latency in a very major way (from ~5 ms to ~250 
ms). See scgi-max-allow.md in the attachments for some detailed data samples. 
The effect levels out at 256. There isn't an obvious difference between 256, 
1024, 4096, and 16384. I've pushed the update to run the tests at 
#:scgi-max-allow-wait 256.

Besides scgi-max-allow.md, I've also attached the results for 1) a five-minute 
benchmark with one concurrent connection, 768 MiB RAM, no swap, 
#:scgi-max-allow-wait 4; 2) a rerun of the first benchmark with the updated 
settings (three minutes, 100 connections, 768 MiB RAM, no swap, 
#:scgi-max-allow-wait 256).

-- 
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.
> grep Requests results/*
results/caddy.txt:Requests per second:4117.47 [#/sec] (mean)
results/compojure.txt:Requests per second:5127.98 [#/sec] (mean)
results/flask.txt:Requests per second:1077.55 [#/sec] (mean)
results/guile.txt:Requests per second:2053.89 [#/sec] (mean)
results/plug.txt:Requests per second:5042.51 [#/sec] (mean)
results/scgi.txt:Requests per second:2760.30 [#/sec] (mean)
results/sinatra.txt:Requests per second:312.66 [#/sec] (mean)
results/stateful.txt:Requests per second:529.93 [#/sec] (mean)
results/stateless.txt:Requests per second:620.32 [#/sec] (mean)

> grep -A 29 'Concurrency Level' results/*
results/caddy.txt:Concurrency Level:  100
results/caddy.txt-Time

Re: [racket-users] Re: Racket Web servlet performance benchmarked and compared

2017-09-02 Thread Piyush Katariya 
Thanks for the clarification.

On 03-Sep-2017 12:31 AM, "George Neuner"  wrote:

>
> On 9/2/2017 1:46 PM, Piyush Katariya wrote:
>
>> Does Racket app make use of all CPU cores by having multiple processes ?
>>
>
> If it is written to use "places", which are parallel instances of the
> Racket VM that run on separate kernel threads.
> https://docs.racket-lang.org/guide/parallelism.html?q=place#
> %28tech._place%29
>
> What Racket calls "threads" are "green" [user space] multiplexed on a
> single kernel thread.
> https://en.wikipedia.org/wiki/Green_threads
>
> George
>

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

Re: [racket-users] Re: Racket Web servlet performance benchmarked and compared

2017-09-02 Thread George Neuner 


On 9/2/2017 1:46 PM, Piyush Katariya wrote:

Does Racket app make use of all CPU cores by having multiple processes ?


If it is written to use "places", which are parallel instances of the 
Racket VM that run on separate kernel threads.

https://docs.racket-lang.org/guide/parallelism.html?q=place#%28tech._place%29

What Racket calls "threads" are "green" [user space] multiplexed on a 
single kernel thread.

https://en.wikipedia.org/wiki/Green_threads

George

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

Re: [racket-users] Re: Racket Web servlet performance benchmarked and compared

2017-09-02 Thread Piyush Katariya 
Then it might not be a fair benchmark with a comparison to other Platforms. 
Isnt it ? 

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

Re: [racket-users] Re: Racket Web servlet performance benchmarked and compared

2017-09-02 Thread Philip McGrath 
The Racket web server does not make use of multiple CPU cores, but with
stateless continuations you can run multiple instances behind a reverse
proxy. See
https://groups.google.com/d/topic/racket-users/TC4JJnZo1U8/discussion ("it
is exactly node.js without callbacks").

-Philip

On Sat, Sep 2, 2017 at 12:46 PM, Piyush Katariya  wrote:

> Just curious ...
>
> Does Racket app make use of all CPU cores by having multiple processes ?
>
> In go app, there isnt any need to becoz golang runtime uses all CPU
> avialble by default. So is the case with JVM and Erlang VM
>
> --
> 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.

[racket-users] Re: Racket Web servlet performance benchmarked and compared

2017-09-02 Thread Piyush Katariya 
Just curious ... 

Does Racket app make use of all CPU cores by having multiple processes ?

In go app, there isnt any need to becoz golang runtime uses all CPU avialble by 
default. So is the case with JVM and Erlang VM

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

Re: [racket-users] Choose Language menu too Long when selecting Legacy languages

2017-09-02 Thread Srinivas K 
Thank you for the suggestion. It works this way and I can atleast Click Okay if 
I open Other languages accidentally. Hope they fix it.

On Saturday, 2 September 2017 18:07:30 UTC+5:30, Royall Spence  wrote:
> Looks like the resize handles on the edge of the window don't do
> anything. Until that's corrected (if it can be), the X window system
> allows you to hold  and click anywhere in a window to drag it
> around the screen. Hopefully that'll allow you to drag the top portion
> off the screen and click the buttons at the bottom.
> 
> On Sat, Sep 2, 2017, at 06:37 AM, Srinivas K wrote:
> > I just installed DrRacket in Racket 6.10 in Manjaro Linux to work my way
> > through SICP. When selecting a language through Choose Language if I
> > click Other Languages the dialog box becomes too long to be accomadated
> > in my monitor and so the Ok button disappears. Is it a bug with the GUI
> > in DrRacket?
> > 
> > -- 
> > 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.

Re: [racket-users] Choose Language menu too Long when selecting Legacy languages

2017-09-02 Thread 'Royall Spence' via Racket Users 
Looks like the resize handles on the edge of the window don't do
anything. Until that's corrected (if it can be), the X window system
allows you to hold  and click anywhere in a window to drag it
around the screen. Hopefully that'll allow you to drag the top portion
off the screen and click the buttons at the bottom.

On Sat, Sep 2, 2017, at 06:37 AM, Srinivas K wrote:
> I just installed DrRacket in Racket 6.10 in Manjaro Linux to work my way
> through SICP. When selecting a language through Choose Language if I
> click Other Languages the dialog box becomes too long to be accomadated
> in my monitor and so the Ok button disappears. Is it a bug with the GUI
> in DrRacket?
> 
> -- 
> 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.

[racket-users] Choose Language menu too Long when selecting Legacy languages

2017-09-02 Thread Srinivas K 
I just installed DrRacket in Racket 6.10 in Manjaro Linux to work my way 
through SICP. When selecting a language through Choose Language if I click 
Other Languages the dialog box becomes too long to be accomadated in my monitor 
and so the Ok button disappears. Is it a bug with the GUI in DrRacket?

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