Importance of HTTP connection keep-alive

[Fabian Keil]

Juliusz Chroboczek <Juliusz.Chroboczek at pps.jussieu.fr> wrote:

> Michael Gersten:
> 
> > getting keep-alive to work will help a lot with web browsing,
> 
> Fabian Keil:
> 
> > Is this an assumption or did you just forget to show your benchmarks
> > to back this claim up?
> 
> I've just tested this by running
> 
>    wget -p http://www.kde.org/screenshots/

No, you tested wget, which doesn't do parallel requests.

The results are certainly interesting and may or may not
show the difference between serialised requests that are
done with and without keep-alive, but the numbers are worthless
to make any assumptions about web browsing.

Any modern browser I'm aware of uses multiple parallel
connections if keep-alive isn't used, Firefox certainly does.

> Please feel free to repeat my tests and report the results on this list.

I have no reason to doubt your results, I just don't
think they are relevant for web browsing.


I just did some tests which I think are more meaningful.

I used Firefox instead of wget, used the Fasterfox plug-in
to time the requests and tried several proxy combinations.

The versions were Tor 0.1.2.9-rc, Firefox 2.0.0.3,
Polipo 0.9.99.1 and Privoxy's CVS version with some
uncommitted modifications which should be irrelevant
for this test.

I didn't change my Privoxy configuration, which means
there were several actions active, some of which effected
the results. http://www.kde.org/screenshots/ contains
no ads or tracking pixels, so filtering the page causes
a delay without any gain.

The test was done on a laptop with FreeBSD's powered(aemon)
running. As a result the CPU frequency wasn't constant,
but I doubt that it mattered for the end results.

I first did five tests for every proxy combination,
switching the proxy combination after each request.

Requests where started with ctrl+F5 so Firefox didn't
use its cache and additionally set the headers
"Pragma: no-cache" and "Cache-Control: no-cache".

I started Polipo with:
polipo diskCacheRoot='' socksParentProxy=10.0.0.2:9050
and restarted it for every test. I kept Tor and Privoxy
running all the time.

Finally the numbers, the format is:
|Proxy combination
|results in the order I got them
|average all
|average without the best and worst result
|average without the two worst results


With http://www.kde.org/screenshots/:
Firefox + Privoxy + Polipo + Tor:
40.950s, 6.100s, 6.294s, 24.290s, 56.680s
26.863s
23.845s
12.228

Firefox + Privoxy + Tor
59.523s, 7.493s, 6.822s, 156.438s, 35.282s
53.112s
34.099s
16.532

Firefox + Polipo + Tor
14.558s, 38.840s, 12.100s, 5.548s, 26.370s
19.483s
17.676s
10.735

I also tested with another website (http://www.spiegel.de/):

Firefox + Privoxy + Polipo + Tor:
155.674s, 46.256s, 141.360, 47.120s, 35.967s
85,275s
78,245s
43,117s

Firefox + Privoxy + Tor:
110.619s, 78.505s, 20.397s, 36.926s, 73,442s
63.983s
62,956s
43,588s

Firefox + Polipo + Tor:
93.979s, 33.102s, 34.242s, 123.365s, 99.740s
76.886s
75.987s
53,774s

Privoxy may have had a slight advantage here,
because by removing three tracking pixels it had
to do three requests less. However I think that
it didn't matter much.

The speed of the underlying Tor circuits seems
to be the most important factor here and five
samples probably aren't enough to prove anything.

It certainly looks like keep-alive's effects aren't
big enough to guarantee faster web browsing through
Tor, though.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20070418/1a278988/attachment.pgp>