With apache everything works fine even from wan. I also did tcpdumps at
my external and internal interfaces on my firewall, which show that the
packets aren't delayed by the fw by no more than 0.1ms. They also show
that the ack for the GET is returned almost instantly but the http
payload doesn't begin to send until about three seconds later (at least
according to my limited knowledge of ethereal). Once the sending
starts, it's all finished in milliseconds and the next lag occurs when
the client GETs another file.
Any idea what could be happening? It's making development testing quite
hard, since all my volunteer testers get fed up with waiting for
pageloads.
Strange. :-( I don't have any real ideas, although you could point some
prints with timing statements into the code if you really wanted to work
this out.
Using the development server for anything beyond single person use is
always going to be frustrating. One of the things about it is that it is
single threaded, so everybody is going to be queuing up to do one
request at a time and if you are also serving images and other static
files that way (not at all uncommon for development), it's going to take
ages. So it's not something we're likely to spend much time trying to
improve, although if you find an obvious "here's a one-line change that
would make some brain-damage go away" type of fix, certainly send it in.
Using apache + mod_python + the PythonAutoReload directive might make
things simpler for you (since you mentioned you already had worked out
the Apache side of things) in these cases.
Regards,
Malcolm
Hmm, I'll look into the source and see if I can make the server print
something. If it doesn't work, I guess I just have to set Apache up.
Wouldn't think that as necessary though, since there is no problems in
the local subnet...
You know, I've recently seen this same exact problem when running the
development server on an IP address other than 127.0.0.1. I've been
meaning to take a look at it, as it's quite frustrating. If you come
up with any solutions, please share!
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
In my experience, when you encounter non-obvious but fairly consistant slow
downs in net traffic, the first thing to check is DNS.
In this case, I'd make sure that each of the DNS cache servers that the client
consults to resolve the address of your server can perform both a forward and
reverse lookup of your server's name an IP.
Conversely, make sure the server isn't being slowed down by failed attempts at
reverse lookups on the client.
HTH,
John
You are correct, if I add the client machine to /etc/hosts on django
server, everything is smooth. However I find quite odd that the server
does a separate reverse dns checks for every GET it gets even in the
same connection...
Turn this off in your Apache httpd.conf with:
HostnameLookups off
It was defaulted to on in older versions of Apache to make the logs
more readable but impacts performance (as you well know).
-Dave
Um, Dave? The original poster was using the development server. Apache
doesn't get a seat at the table here. :-)
Cheers,
Malcolm
Er ... in my best Emily Litella impression: "Never mind"
I've fixed this as of http://code.djangoproject.com/changeset/3530 .
Thanks for bringing it up!
Works like a charm. thanks. Such a tiny piece of code... :)