Intranet access to server slower than via the Internet

Question

I have many computers in my Intranet in the same subnet, connected through a hub. All the computers in subnet gets IP from built in DHCP of the router. Also, all computers get Internet connection from the same router.

I have an Internet server in one of the computers (192.168.0.67), in same subnet. It has Windows XP, Apache, MySQL and Perl. The site loads perfectly in localhost. When I try to load that site in client computer (IP 192.168.0.100) with Windows 7, it takes 5-10 minutes to load even a simple page. However, when I load site from Internet it loads quickly. No matter which browser I use, it is very slow. I have disabled Windows firewall and antivirus software in both computers.

When I checked taskmgr for network load, it consumes about 0.1-0.2%. In the performance tab, the CPU usage is about 10% and I have plenty memory in both computers

When I ping server with low payload, it does well. But when I ping server with high payload (higher than ping server -l 15000) many packets are lost.

Answer 1

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.

Answer 2

Windows XP added the limitation of a maximum number of active connections for client operating systems (I believe the number is 10, but am not entirely sure about that part of it). This means that if you're running a server on that machine and more than that number of connections are being made to the system, a number of your clients will have to wait until a previous client is ready.

You should probably replace that Windows XP by something else, and that will fix it -- even on the same hardware.