Make sure HostnameLookups is set to Off
in Apache.
You say the server is running Apache, correct? Well if that is the case open up httpd.conf
or apache2.conf
(all depends on how it was installed on your setup; both files are basically the same) and look for a configuration line with HostnameLookups
in it. By default HostnameLookups
is set to Off
as explained in the comment that should be right above the HostnameLookups
setting in that file; bold emphasis is mine:
HostnameLookups: Log the names of clients or just their IP addresses
e.g., www.apache.org (on) or 204.62.129.132 (off). The default is
off because it'd be overall better for the net if people had to
knowingly turn this feature on, since enabling it means that each
client request will result in AT LEAST one lookup request to the
nameserver.
And the official Apache documentation goes into deeper detail as well; again bold emphasis is mine:
The default is Off in order to save the network traffic for those
sites that don't truly need the reverse lookups done. It is also
better for the end users because they don't have to suffer the extra
latency that a lookup entails. Heavily loaded sites should leave this
directive Off, since DNS lookups can take considerable amounts of
time.
Don’t use hostnames for Allow from
/Deny from
directives.
Also, do you have any directories or directives that use Apache Basic Auth? Which is the simply password protection one can set in Apache? I recall in some cases there were slowdowns related to hostname lookups connected to Allow from
fields such as an Allow from localhost
. Commenting out Allow from localhost
or setting that to Allow from 127.0.0.1 ::1
and then restarting Apache would clear that up.
As explained in the official Apache documentation even with HostnameLookups
set to Off
using full hostnames in Allow from
/Deny from
directives will trigger a whole chain of DNS lookups that can slow down access; bold emphasis is mine:
Hosts whose names match, or end in, this string are allowed access.
Only complete components are matched, so the above example will match
foo.apache.org but it will not match fooapache.org. This
configuration will cause Apache to perform a double reverse DNS lookup
on the client IP address, regardless of the setting of the
HostnameLookups directive. It will do a reverse DNS lookup on the IP
address to find the associated hostname, and then do a forward lookup
on the hostname to assure that it matches the original IP address.
Only if the forward and reverse DNS are consistent and the hostname
matches will access be allowed.
This blog post also explains it nicely if you care to read more details on how Allow from
/Deny from
entries that have a hostname—instead of a raw IP address—can slow down Apache access because of multiple DNS lookups:
However, I recently came across a situation where we inadvertently
were doing the equivalent without explicitly enabling HostnameLookups.
How? By limiting access based on the remote hostname! Read the
documentation on the Allow directive, under the section "A (partial)
domain-name":
This configuration will cause Apache to perform a double reverse DNS
lookup on the client IP address, regardless of the setting of the
HostnameLookups directive. It will do a reverse DNS lookup on the IP
address to find the associated hostname, and then do a forward lookup
on the hostname to assure that it matches the original IP address.
Only if the forward and reverse DNS are consistent and the hostname
matches will access be allowed. This makes perfect sense, but it is a
pretty big likely unexpected side effect to using something like:
Allow from .example.com
In our case it was an even less obvious case that didn't make us think
of hostnames at all:
Allow from localhost
Here localhost was written, perhaps to save some effort or maybe
increase clarity vs. writing out 127.0.0.1 (IPv4) and ::1 (IPv6).
Mentally it's so easy to view "localhost" is a direct alias for
127.0.0.1 and ::1 that we can forget that the name "localhost" is just a convention, and requires a lookup like any other name. Those
familiar with the MySQL database may know that it actually assigns
special confusing meaning to the word "localhost" to make a UNIX
socket connection instead of a TCP connection to 127.0.0.1 or whatever
"localhost" is defined as on the system!
You may also be thinking that looking up 127.0.0.1 is fast because
that is usually mapped to "localhost" in /etc/hosts. True, but every
other visitor who is not in /etc/hosts gets the slow DNS PTR lookup
instead! And depending on the operating system, you may see
"ip6-localhost" or "ip6-loopback" (Debian 7, Ubuntu 12.04),
"localhost6" (RHEL 5/6, Fedora 19) in /etc/hosts, or something else.
So it's important to spell out the addresses:
Allow from 127.0.0.1
Allow from ::1
Doing so immediately stops the implicit HostnameLookups behavior and
speeds up the website. In this case it wasn't a problem, since it was
for a private, internal website that couldn't be visited at all by
anyone not first allowed through a firewall, so traffic levels were
relatively low. That access control is part of why localhost needed to
be allowed in the first place. But it would have been very bad on a
public production system due to the slowdown in serving traffic.
If you have many computers in your local network, have you tried another client computer to see if that one has the same problems? Try to determine if the problem is in the network or in that one computer! – SPRBRN – 2015-02-25T11:34:46.197
What is the make and model of the device the machines are connected to? Have any of the computers had their speed and/or duplex settings changed from the default? – David Schwartz – 2015-02-25T11:49:52.457
2When you really use a hub and have that delays (5-10 minutes) then most likely one of the pc is working with fullduplex. Check the state of the network cards. – marsh-wiggle – 2015-02-25T12:09:36.497
I recently formatted that computer, thinking that that specific computer might have error. But the problem remsins same after that – Prabhu – 2015-02-25T18:20:20.330
Try to disable IPv6 in your internal network. Please post the output of tracert to the server. – harrymc – 2015-09-12T11:34:46.790
5Are you using a hub? (and e.g. 10mbit coax), or are you using a switch? Hubs are bad, but have not been on the common market for nearly a decade. – Hennes – 2015-09-12T11:50:29.450
1I am using a switch instead of hub – Prabhu – 2015-09-12T18:49:23.883
1Harrymic, This was an old issue, I solved it by creating a new virtual LAN with server and clients that use the web server. I will try to disable IPV6 and run the service without virtual LAN to check if your suggestion works – Prabhu – 2015-09-13T17:32:14.653
Small thing to point out about this question, “Windows XP, Apache, MySQL and Perl” Shouldn’t that be PHP instead of Perl? Most LAMP/WAMP/MAMP stacks are focused on PHP as the core scripting language. – JakeGould – 2015-09-14T19:57:16.523