On Saturday, September 2, 2017 at 8:46:54 PM UTC+3, Piyush Katariya wrote:
> Does Racket app make use of all CPU cores by having multiple processes ?

Thanks for asking this question. It prompted me to revise how the benchmark is 
run. The short answer is that the servlet application uses a single core. The 
SCGI application is the same way, but benefits from nginx's built-in support 
for multicore through worker processes.

I've made the servlet application use futures according to Jay McCarthy's post 
at https://lists.racket-lang.org/users/archive/2014-July/063419.html, but found 
that, as he predicted, it did not improve the performance (in fact, it reduced 
it). I don't know straight away how to implement places-based workers for 
servlets. I may investigate it later (I'm interested in message-passing 
parallelism), but my primary intention with this project is to measure the 
performance a developer gets out of existing, reusable, hopefully already 
debugged libraries and frameworks. A little custom code and configuration is 
fine, but a custom work scheduler seems to me to go beyond that. Does a library 
exist for running servlets in places?

I've also experimented with having nginx load balance between two Racket SCGI 
instances. The result was somewhat better throughput (~2650 req/s instead of 
~2300 req/s) and identical latency when the application had two cores to work 
with, and worse throughput (~1800 req/s) and latency with only one.

As far as fairness goes, I don't think either a strictly single-core or a 
use-them-if-you-can multi-core benchmark is clearly unfair. Both types have 
value. After some consideration, I've decided to commit to single-core (sort of 
— read on) as the default for this benchmark.

My first solution was to limit the VM in which I ran the benchmarks to a single 
core, but that lead to ApacheBench and the application competing for CPU time. 
This would take the benchmark further away from the real world, and it is 
generally not recommended to have the benchmarked application and the load 
generator share a CPU. I've tried a few solutions, and the best I have found in 
terms of how the resources are allocated is to bind each of the two containers 
(the application and ApacheBench) to a separate CPU core. That way the 
applications get only one core, but don't have to fight for it with 
ApacheBench. I've pushed this update to the repository.

Here are some numbers for the three configurations: one core, two cores, and 
one core per container.

-- 1 shared core
results/caddy.txt     -Requests per second:    2312.93 [#/sec] (mean)
results/compojure.txt -Requests per second:    1677.89 [#/sec] (mean)
results/flask.txt     -Requests per second:     977.33 [#/sec] (mean)
results/guile.txt     -Requests per second:    1508.77 [#/sec] (mean)
results/plug.txt      -Requests per second:    2335.21 [#/sec] (mean)
results/scgi.txt      -Requests per second:    2163.00 [#/sec] (mean)
results/sinatra.txt   -Requests per second:     317.75 [#/sec] (mean)
results/stateful.txt  -Requests per second:     494.55 [#/sec] (mean)
results/stateless.txt -Requests per second:     584.34 [#/sec] (mean)

-- 2 shared cores
results/caddy.txt     -Requests per second:    4358.68 [#/sec] (mean)
results/compojure.txt -Requests per second:    4730.50 [#/sec] (mean)
results/flask.txt     -Requests per second:    1140.01 [#/sec] (mean)
results/guile.txt     -Requests per second:    2092.78 [#/sec] (mean)
results/plug.txt      -Requests per second:    5235.78 [#/sec] (mean)
results/scgi.txt      -Requests per second:    3074.15 [#/sec] (mean)
results/sinatra.txt   -Requests per second:     329.35 [#/sec] (mean)
results/stateful.txt  -Requests per second:     604.30 [#/sec] (mean)
results/stateless.txt -Requests per second:     687.77 [#/sec] (mean)

-- 2 fixed cores (one for "benchmarked", one for "ab")
results/caddy.txt     -Requests per second:    3963.03 [#/sec] (mean)
results/compojure.txt -Requests per second:    2513.05 [#/sec] (mean)
results/flask.txt     -Requests per second:    1207.77 [#/sec] (mean)
results/guile.txt     -Requests per second:    2133.48 [#/sec] (mean)
results/plug.txt      -Requests per second:    4322.55 [#/sec] (mean)
results/scgi.txt      -Requests per second:    2406.02 [#/sec] (mean)
results/sinatra.txt   -Requests per second:     347.89 [#/sec] (mean)
results/stateful.txt  -Requests per second:     573.48 [#/sec] (mean)
results/stateless.txt -Requests per second:     658.67 [#/sec] (mean)

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