Richard Schneeman

Running with 6.6.1 and `max_fast_inline(0)`: ``` rack-jruby: - max_fast_inline: 0.0 ``` I get a similar ballpark as 6.6.1, it is `51,772` which is slightly lower, but still much higher than...

@joshuay03 yep, but `wait_until_not_full` applies to both clustered and non-clustered. But based on the numbers, it doesn't look like this problem involves it. The puma 6.6.1 case was not getting...

Edit: This is invalid, see next comment On puma 6.6.1, making this patch effectively turns off pipelining: ```diff --- a/lib/puma/server.rb +++ b/lib/puma/server.rb @@ -469,7 +469,7 @@ module Puma while true...

Update. I think the reason numbers are so similar is that if you use `&& false` then you end up in a situation where the response does not say the...

If the problem is "removing fast inline makes thing slow" a reasonable fix is "reintroduce fast inline," but add guards to ensure that the old problematic behavior doesn't happen. https://github.com/puma/puma/pull/3794

Good news and bad news. Good: On my local benchmark, my PR is **faster** than 6.6.1 and 8x faster than 7.0.4 ``` v6.6.1 Requests/sec: 116,403.14 v7.04 Requests/sec: 20,968.15 My branch...

I thought max keep alive default was 999 now. Back to the reproduction drawing board. This is weird.

Thanks a ton for the extra information. Since I'm not able to see/reproduce this behavior with the techempower docker benchmarks, I wonder if it's possibly related to CPU architecture (I'm...

I mostly traffic in SIGTERM and SIGKILL. I'm unsure of the possible negative implications of this setting or what users may be expecting or find surprising. I would expect that...

I just swapped the default branch name from `master` to `main`, you don't need to do anything for this PR. You'll need to update your local environment accordingly: ``` $...