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.
