Hi David, I can at least confirm the issue on ab. And the stress can be reduced a lot for better debugg-ability:
$ ab -k -n 1 -c 1 https://DavidFavor.com/foo-8192.txt | grep '^Time per request.*mean)$' Time per request: 397.659 [ms] (mean) $ ab -k -n 1 -c 1 https://DavidFavor.com/foo-8193.txt | grep '^Time per request.*mean)$' Time per request: 5400.170 [ms] (mean) So one byte makes the request x13 longer. But as one single request shows the same issue, we can compare much easier: $ time wget https://DavidFavor.com/foo-8192.txt --quiet real 0m0.416s $ time wget https://DavidFavor.com/foo-8193.txt --quiet real 0m0.416s So yeah, something in ab most likely. I checked that with the version in Artful to not face a known issue - but it still is occuring there. Checking with "strace -rT" reveals that it is just about as fast with 8193 than 8192. Except there is a last final call on epoll_wait with 5 seconds. That together with many definitions in ab being on 8192 I'd assume it fails to understand that it is done by exceeding some buffer and then opens up a new epoll which is on a 5 second timeout. That is clearly an upstream problem (or they consider >8192 not supported). Would you mind reporting there and posting the bug reference here then? That would be very kind. In terms of an "ubuntu bug" this is "confirmed" but not really actionable. Thanks btw for creating an online setup one can reuse to test this! ** Changed in: apache2 (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1704168 Title: Apache-2.4.27 massive slow down for files >8192 bytes long To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1704168/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
