Apache: internal dummy connection

In the last few days I’ve been working on optimizing my server’s performance. While I was investigating the Apache requests I noticed that there was a constant number of requests opening the main page of the default virtual host. As the default virtual host used to redirect to another virtual host using mod_rewrite, I was unable to track the HTTP referrer. I disabled the redirect rule, put an empty index.html and enabled access.log for this website. It was quite surprising to notice the following repetitive entry in it:

“a.b.c.d” was one and the same IP. One of my IPs in a matter of fact. Holy crap! It seems Apache does some kind of internal request to this page. Hopefully I used a “[R]” modifier to my mod_redirect rule. Otherwise it would probably cause an internal subrequest. As the target page is dynamic this would cause some a noticeable overhead…

I Google’d for “(internal dummy connection)”. There were only a few results explaining what was really happening… many of them were rumors. I found an entry in Yenya’s blog with the same issue. It suggested this is a replacement in Apache 2.x of sending signals to its processes as signals are not available on all platforms. This means during graceful restart, instead a SIGUSR1 to be sent to all child processes, a subrequest is made. The CodeSearch results seem to confirm this. Now, let’s say my server is running ~100 processes and I change anything in my configuration. Would this mean ~100 subrequest at a time? Yeah, this would be an overhead (over- an already loaded server’s -head)! Oh, my web servers is being gracefully reloaded each time a log is rotated… ~50 times.

It seems this feature exists in the whole 2.x series so a downgrade to 2.0 would not solve this issue. It’s just in versions prior to 2.2.0 there was no indication of such internal requests. People proposed switching to Worker MPM. However, some claim on 2.6.x boxes (my case) Prefork MPM runs faster. Additionally, PHP is not thread-safe by default (Worker MPM is thread based) and it should be compiled with Zend Thread Safety libraries (–enable-experimental-zts). I don’t think it’s worth… It would be great if there was a way to switch back to the old behaviour on platforms that support it… it’s odd otherwise. Now I’ve disabled the logging for the default website and I’ve left mod_redirect (as I don’t think Apache would follow redirects internally).

P.S.: I suppose signals are also used to terminate a child when the number of request reaches MaxRequestsPerChild, so I experimentaly disabled this limit as it’s used to protect the system from any memory leaks in child processes. However, I haven’t noticed any by now. I hope this will decrease the number of signals sent to the child processes. Let’s check this out…

@Trailmug: I’ve come accross this solution too but I intentionally skipped it as there is a minor performance issue with it. I hope there’ll find another way to achieve the same result, as these results are literally dummy.

Sure Valery. We had extremly high loads when restarting or starting Apache 2.2.4 on FreeBSD 6.2 with the latest Mod_Python. It turned out to be Mod_Python and our Django app. We eventually tried running it on SCGI and it solved the problem. It’s also a bit faster and there is less to setup.

Not really on-topic, but that was the problem. Since then the dummy connections have not been much of a problem.

Just found this page while browsing the net for some answers. One idea I just came up with (you’ve probably already thought of and discarded it) is to have the default virtual host only display a very simple HTML page (e.g. the default ‘It works’ page), and have it responsible for no actual hostnames/IPs except for 127.0.0.1. Then, setup a virtual host for your actual site.