Wednesday, June 30, 2010

Internal Dummy Connection

Today I heard a conversation on the subject line just a few cubicles away, and it reminded me of something which I met quite some time back in a very heavy way in my Apache access logs. In my last assignment, I was working on optimizing my server’s performance and was investigating each and every Apache requests that were coming to my server, and surprisingly Iwhat I saw was that -there were constantly a number of requests opening the main page of the default virtual host. - - [22/Sep/2009:12:05:15 -0400] "GET / HTTP/1.0" 200 2269 "-" "Apache/2.2.8 (Red Hat) (internal dummy connection)"

I searched what it is and found in Apache Documentation Wiki the actual idea behind.

Upon further research I came to know that the main Apache process apparently contacts its children not by sending them the SIGUSR1 signal, as in previous Apache releases, but instead sends them a dummy request "GET /", so that they can after the request check (and find out) that the configuration has been changed, and terminate themselves

Now since we know what it is, lets try to understand the concern around it:
  1. This causes unnecessary confusion, a mess and kind of noise in the log file, which creates problem when we go for log anaylyzer.
  2. "GET /" which actualy hits the main page of the default VirtualHost might incur the cost of dynamic content generation for /
For both the above points, if it is really an annoyance to grep out while analyzing access logs, probably what we can do is a directing this request to a valid page, which takes very less resource.

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^.*internal\ dummy\ connection.*$ [NC]
RewriteRule ^/$ /nothing.html [L]

So the idea here is, since you can't keep Apache from sending all of these requests to itself,one thing you can do is to respond to them in a manner that requires the lowest possible resources.

But one advice here would be that - if you are seeing too many child processes spawn and die, you may want to have a closer look at your MinSpareServers and MaxSpareServers directives, and your MaxRequestsPerChild. If MaxRequestsPerChild is very small(people usually do this, to avoid memory leak for doubtful code/application) this is quite imminent.

So, in short "Internal Dummy Connection" is usually not something to be worried about much , but odd pattern must be investigated as it might be a hint of some wrongly judged MPM parameter setting that has gone live and this probably also can help us prevent Apache going for a 'busy for nothing' scenario if the default page is really very heavy with dynamic content!


No comments:

Post a Comment

CICD Assessment

( A story on -  how we formulated a process around measuring and achieving CICD, and  how these journey lines has now become a means t...