Patrik Ragnarsson

Hmm. https://github.com/puma/puma/issues/2625, https://github.com/puma/puma/issues/1565

Can we trust `ab`? https://httpd.apache.org/docs/2.4/programs/ab.html states under "Bugs" > It does not implement HTTP/1.x fully; only accepts some 'expected' forms of responses.

Puma has been benchmarked extensively using the `wrk` fork by @ioquatix https://github.com/ioquatix/wrk, see https://github.com/puma/puma/blob/master/docs/testing_benchmarks_local_files.md for some docs about that I tried this myself just now: ``` $ WEB_CONCURRENCY=2 PUMA_MAX_THREADS=1 b...

I think you're just experiencing the nature of keepalive? Try more Puma threads and/or workers?

Using https://github.com/rakyll/hey I see the same thing as you: ``` $ hey -n 5000 -c 100 http://127.0.0.1:9292 Summary: Total: 3.5634 secs Slowest: 1.7245 secs Fastest: 0.0000 secs Average: 0.0288 secs...

If I run Puma with more threads: `WEB_CONCURRENCY=2 b e puma --threads 16:16 hello.ru` `Requests/sec` matches the numbers we get with `-disable-keepalive` and 1 thread per Puma worker ``` $...

But you have completely different software in front of Puma with Heroku vs AWS?

If you aren't maxing out resources, you have room for more Puma threads? :) I can understand that you expect similar performance or better with keep-alive. It makes sense. Someone...

If I add `max_fast_inline 0` to the Puma config, `hey -n 5000 -c 100 http://127.0.0.1:9292` gives me `Requests/sec: 26195.1310` for 2 puma workers with 1 thread each. ``` $ hey...

> If I add `max_fast_inline 0` to the Puma config, `hey -n 5000 -c 100 http://127.0.0.1:9292` gives me `Requests/sec: 26195.1310` for 2 puma workers with 1 thread each. `queue_requests false`...