Created attachment 38253 [details] Random files taking 5 seconds to be served Since httpd 2.4.47 on my macbook pro running MacOS 12.3.1, files can take 5 seconds to be served as you can see on the screenshot. If I downgrade to 2.4.46, the problem disappears. When searching on Google, I found this stackoverflow thread that can be helpful: https://stackoverflow.com/questions/70698918/apache-http-localhost-randomly-taking-5-seconds-on-macos-monterey-but-fast-on-ht That's also in this thread that someone found that if you set KeepAlive to Off, the problem disappears too.
Does the problem also appear with 2.4.53? Which MPM is used?
Yes, the problem also appear with 2.4.43, I'm using mpm_prefork
2.4.43 or 2.4.53?
What is your KeepaliveTimeout and your Timeout setting?
I meant 2.4.53, sorry 🤦♂️. I use the default configuration for KeepaliveTimeout which seems to be 5 seconds. If I change it to 2 seconds for instance, I can see that it has an impact and files randomly take 2 seconds to be served. Timeout is set to 60.
Please reproduce on 2.4.53 with "LogLevel trace8" and attach the error_log here.
Also with LogLevel trace8, loading mod_dumpio like the below: LoadModule dumpio_module modules/mod_dumpio.so DumpIOInput on DumpIOOutput on would be useful.
The file is too big to be attached here, I uploaded on my dropbox: https://www.dropbox.com/s/xrt4l1vi6hyhizs/error_log?dl=0
To add a little more context, during the request logged, 3 files took 5 seconds to be served: jquery.min.js?v=5.1.3, bootstrap.bundle.min.js?v=5.1.3 and jquery-ui-timepicker-addon.js?v=5.1.3
On the httpd side it seems that those files are sent/flushed in a timely manner (within the same second), and then 5 seconds later the connection is closed because no new request arrives before the keepalive timeout. Somehow the client/browser thinks the response is incomplete until the connection is closed, while it looks complete from the HTTP protocol point of vue (as shown in the traces). Could you please capture a network trace on localhost (since both httpd and the client seem to be there) with something like (as root probably): # tcpdump -s0 -w /tmp/66019.cap tcp port 80 and attach "66019.cap" here? (note that you can [g]zip the attachments before attaching them to reduce their size)
Created attachment 38255 [details] Result of tcpdump For this request, 3 files took 5 seconds to be served: theme.css?v=5.1.3&nocache=996186ltr&server=1, jquery-ui-timepicker-addon.js?v=5.1.3 and functions.js?v=5.1.3
Created attachment 38256 [details] Handle TCP_CORK vs TCP_NOPUSH peculiarities From the network traces, it seems that TCP packets are not PSH-ed appropriately on OSX, the last packet could be retained in the TCP stack until the connection is closed. We may need to handle TCP_CORK on Linux and TCP_NOPUSH on BSDs/OSX differently in the core output filter, could you please try this patch on your system?
Created attachment 38257 [details] Result of tcpdump after patch Just tried with the patch, I still have the problem. I attached the result of tcpdump with the patch, 3 files took 5 seconds: theme.css?v=5.1.3&nocache=1438139389ltr&server=1, bootstrap.bundle.min.js?v=5.1.3 and jquery-ui-timepicker-addon.js?v=5.1.3
Created attachment 38258 [details] Disable TCP_NOPUSH on OSX I read that OSX does not release corked data when unsetting TCP_NOPUSH (until the connection is shutdown?), which is not compatible with how httpd's core output filter works. So this patches disables the TCP_NOPUSH optimization on OSX, would you please test it?
I confirm your latest patch works!
Thanks for testing and the great directions. Checking in r1900100 (trunk).
Thanks for your time and reactivity!
Backported to 2.4 (r1901201), will be in the next release.