Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I want to expose my development site to more computers in the house. What I'm finding is that accessing it via an internal ip like 192.168.0.198 is extremely slow compared to hitting localhost .

I'd rather train myself a bit in debugging these situations because there might not be a single answer.

The server is running nginx for static content, redirecting to apache (127.0.0.1:8888) for dynamic django-generated html. I'm also running postgresql and solr for database and search index as well as memcache.

My django settings.py file lists 127.0.0.1 and 192.168.0.198 as it's internal ips. The DB backend is configured for localhost. The memcached and solr backends are configured for 127.0.0.1.

My /etc/hosts file looks like:

127.0.0.1       localhost localhost
192.168.1.198   localhost
127.0.1.1       jacob-desktop
127.0.0.1       redmine

(I was accessing my redmine project management system using a name based virtual host until I installed nginx - that's what that is for).

Interestingly, it seems much faster to access the static home page than the subsequent pages that have DB/memcached/solr access.

A lot of my confusion stems from what exactly the differences between localhost/192.168.0.198/127.0.0.1 are, how these various ips interact with the network infrastructure (in my case, crappy dlink router). Further, there's various systems like solr and postgresql where I'm not sure about the ip's I want to use.

The goal is to configure these areas so that I'm on the right path towards horizontal scalability - which means 127.0.0.1 probably won't be where my db / search index are located.

share|improve this question

2 Answers 2

up vote 0 down vote accepted

I don't have a complete answer here - rather some hints on where I'd start to look...

Usually access to your own IP address is not sent over the wire, e.g. your router should not be involved. There might be some reverse lookup involved, but that seems to be handled through your hosts file...

Regarding your /etc/hosts, I've not seen 192.168.x.x being assigned to the name localhost - that's rather the machine name or any alias you want your machine to reply to.

Also, you can try if

route
route -n

yield some timing results - e.g. the first command performs reverse lookup, the second not.

What doesn't seem to be your problem, but is related:

I've had some speed problems when an IP address was not resolvable - e.g. either reverse DNS lookup or an appropriate /etc/hosts file could help. The reason in this case usually is some logging where a host name lookup is performed that times out when the dns cannot be resolved. This has especially been the case with ssh logins on machines where the client address (rather: name) couldn't be resolved.

share|improve this answer
    
Which of these hints has lead to the solution? What was the solution? –  Olaf Dec 17 '09 at 19:12

In general cases on one machine you'd better use lo0 instead of external interface, because:

  • Loopback's MTU is way higher - 16436
  • Loopback is not using any of hardware drivers, like e1000(Linux) or em0(FreeBSD)
  • Loopback skips some OSI levels when transfers data
  • Loopback don't use some times buggy features like TSO,LRO etc
  • Loopback is always up, even if link on interface is down
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.