Opened 18 years ago
Closed 18 years ago
#3481 closed defect (fixed)
Tracd HTTP response is very slow in windows between PCs.
Reported by: | Owned by: | Christian Boos | |
---|---|---|---|
Priority: | high | Milestone: | 0.10.1 |
Component: | web frontend/tracd | Version: | 0.9.6 |
Severity: | normal | Keywords: | slow network |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
When I installed the trac in standalone way, I found it is very slow to response to browser. But this case only appear in connection from another PC. It means if I access the trac in the local machine, the speed is normal (about 0.0x seconds). I have traced the Trac code and found that: it is fine with good speed in handling the request but stuck in "send_response" step. This situation will add extra 12 seconds cost to response to the browser. Maybe is the IO/Network issue?
e.g. from my trac log— "19:45:49 Trac[standalone] DEBUG: Total request time: 12.032000 s"
Attachments (0)
Change History (10)
comment:1 by , 18 years ago
Milestone: | 0.9.7 |
---|---|
Resolution: | → worksforme |
Status: | new → closed |
comment:2 by , 18 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Trac 0.10 release has same issue.
env:
os: windows 2003 & sp1 python: 2.4.3 standalone mode, tracd -s -d -a…
Browse it in local host will be very quick as my old trac 0.9.5. But it will very very slow from another PC in 100M LAN. It costs >60s!
comment:3 by , 18 years ago
In version 0.10, the following patch does the trick to disable dns reverse lookups (against trac/web/wsgi.py):
—- orig/wsgi.py 2006-11-06 10:36:11.991122600 -0700 +++ wsgi.py 2006-11-06 10:35:16.820306900 -0700 @@ -121,6 +121,9 @@
class WSGIRequestHandler(BaseHTTPRequestHandler):
+ def address_string(self): + host, port = self.client_address[:2] + return host
def setup_environ(self):
self.raw_requestline = self.rfile.readline()
comment:5 by , 18 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
follow-up: 7 comment:6 by , 18 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
(no change committed to the Trac base code)
comment:7 by , 18 years ago
Milestone: | → 0.10.1 |
---|---|
Resolution: | worksforme |
Status: | closed → reopened |
comment:8 by , 18 years ago
Oops, I missed Christians response to this :-P
In any case, I think we should disable reverse lookups in tracd to get rid of this problem. I don't see any value in reverse lookups and pretty much every web server I know has them disabled by default. Plus, tracd is meant for being run either for development, or behind a HTTP proxy.
comment:9 by , 18 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
Well, I'm all for disabling reverse lookups there, choose your patch ;)
The standard python HTTPServer used by TracStandalone will log each client request. While doing this, it tries to resolve the client's numerical IP address to a fully qualified name. You probably don't have a DNS server correctly setup in your environment, hence the slow down.
So either fix that (preferred solution) or, if it's not an option, apply the following patch (hack):
(patch on stable, something similar could be done on trunk; the method is added to the TracHTTPRequestHandler class)