blog-banner

Mitigating Apache Internal Dummy Connection Issue

  • Apache
  • Drupal
  • Drupal Planet

Apache Internal Dummy Connection

 

This is one of the bothering issues we had lately in our project. I'm summarizing the list of causes and possible ways to fix/mitigate the same. So what is Apache's Internal Dummy Connection all about? The Official Wiki page explains it better. See the snip below,

When the Apache HTTP Server manages its child processes, it needs a way to wake up processes that are listening for new connections. To do this, it sends a simple HTTP request back to itself. This request will appear in the access_log file with the remote address set to the loop-back interface (typically 127.0.0.1 or ::1 if IPv6 is configured). If you log the User-Agent string (as in the combined log format), you will see the server signature followed by "(internal dummy connection)" on non-SSL servers. During certain periods you may see up to one such request for each httpd child process.

#1: VirtualHost

As mentioned, Apache makes a call to itself. If your default VirtualHost is configured to serve dynamic database-driven sites like Drupal, it will certainly result in increased resource utilization. Changing the same to serve static index.html should make the dummy HTTP request faster and less resource-intense. Even if you have a directory listing, symbolic links, and/or AllowOverriding turned on, it is suggested to disable them.

#2: .htaccess Rewrite Rule

If default VirtualHost couldn't be changed for some reason, with mod_rewrite you can prevent requests from hitting the Drupal with the rewrite rule.

The below rewrite condition and rule suggests apache responds to a 403 immediately if the HTTP request is meant for an internal dummy connection. This utilizes the least possible resource.

RewriteCond %{HTTP_USER_AGENT} ^.*internal\ dummy\ connection.*$ [NC]
RewriteRule .* - [F,L]

#3: Writing to Log

It can be noted in apache's access.log filled with lines,

127.0.0.1 - - [09/Jun/2015:12:00:10 -0400] "GET / HTTP/1.0" 200 2269 "-" "Apache/2.2.3 (Red Hat) (internal dummy connection)"
127.0.0.1 - - [09/Jun/2015:12:00:11 -0400] "GET / HTTP/1.0" 200 2269 "-" "Apache/2.2.3 (Red Hat) (internal dummy connection)"
127.0.0.1 - - [09/Jun/2015:12:00:13 -0400] "GET / HTTP/1.0" 200 2269 "-" "Apache/2.2.3 (Red Hat) (internal dummy connection)"

This could cause unnecessary I/O operations and could be prevented from logging with the below directives usage in the .conf file,

If IPV6 is on,

SetEnvIf Remote_Addr "::1" dontlog
CustomLog /var/log/apache2/access.log combined env=!dontlog

If IPV6 is off,

SetEnvIf Remote_Addr "127.0.0.1" dontlog
CustomLog /var/log/apache2/access.log combined env=!dontlog

#4: Prefork

Prefork and Worker are two types of MPM apache provides. Default MPM is Prefork which is threaded safe and uses multiple child processes. Reducing mix/max values of Prefork directives should prevent overutilization of resources.

    StartServers         5
    MinSpareServers      5
    MaxSpareServers      10
    ServerLimit          14
    MaxClients           14
    MaxRequestsPerChild  500

#5 Opting for Event MPM

This is a new type of MPM Apache provides and made stable in Apache 2.4 or so. If you’re running the latest version of Apache, go ahead and use the new Event MPM. This MPM tries to fix the 'keep alive problem in HTTP.

#6 Swap

Waking up child processes might require some memory. If your RAM is already full and waking child processes might demand the use of swap space which could further affect the response time. It is noted in my case that Thrashing was happening and the system would hang for a while. Changing swappiness back to its default value of 60 made it better.

Get awesome tech content in your inbox