[Seaside] Strange performance issue with Firefox 3.6/Windows

Sean Malloy smalloy at gmail.com
Wed Mar 24 22:42:37 UTC 2010


TLDR version:

If you are developing on Windows 7 with IP6 enabled, and connecting to
Comanche and suffering a weird 1s request/response lag, edit your
hosts file and un-comment the IP4 definition for localhost, but leave
the IP6 definition commented out. - I'm not sure what the side effects
of doing that are though, but It Works On My Machine! (TM)

Long winded version:

I discovered a strange performance issue that only seemed to affect
Firefox 3.6/Windows 7 connecting to Comanche. I have since found a
work around, and thought I would share it for future reference. I also
discovered that this affects Swazoo/Dolphin, but only on the initial
request, or immediately after a post request.

I downloaded the latest 3.0a5 one-click from seaside.st, and loaded it
up, and found "slow" performance when connecting to
http://localhost:8080/. There was about 1s between the request being
sent by the browser, to the response being received.

I started trying to break down the problem - so I setup a really
simple Comanche service: http://pastebin.com/kxRH874j - still the
issue persisted, so I thought maybe it was some sort of weird Comanche
issue, so I downloaded Swazoo 2.2, and setup a similar basic handler
(by subclassing HTTPServer and overriding #answerTo:, and returning a
HTTPResponse ok etc) - Swazoo was fine?! So this only served to
further re-enforce the thought that it was a Comanche problem.

I changed browsers and tested in IE. Request/Response was snappy
across both Comanche and Swazoo. What the!

I swapped to my Mac, and downloaded Firefox 3.6, and did the same
tests against Comanche and Swazoo. Firefox 3.6 Request/Response was
fine across both, same with Safari. So this was a localised Firefox
3.6/Windows only issue?

So then I started looking at the time between Firefox sending the
request, and the time until the socket was accepted on the Comanche
side, and that's where I found the real delay - Comanche wasn't even
getting hit until about 900ms later. Once Comanche accepted the socket
the latency between accept->Firefox Response was around 30ms or so,
which is about what I would have expected. Out of curiosity I
wondered, what would happen if I browsed to http://127.0.01:8080/
instead. Lo and behold, the request/response delay was gone, so I
thought maybe there was something I'd stuffed in my hosts file, so I
went and checked it, and it was the default host file from
installation, but I noticed that in Windows 7, localhost is now
commented out, and a note saying that localhost resolution is handled
inside windows dns services now. So I thought well what happens if I
uncomment the localhost line, and instantly the request/response lag
in Firefox was fixed. Then I uncommented the second line, which
configured the IP6 version of localhost, and the problem came back.

So while I haven't found an exact cause of the problem, it seems as if
there is some sort of Firefox 3.6-win7/Comanche/IP6 issue at play
here. The work around for me is to just keep ip4 localhost uncommented
in my hosts file, and the irritating request/response issue goes away

Ofcourse, I could have just used instead, but
the habit of typing in localhost.... argh.

PS this is a development only issue, in production there is no
perceivable issue, but in dev... painful/irritating yes.

More information about the seaside mailing list