[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kio_http, persistent connections
From:       Rik Hemsley <rik () kde ! org>
Date:       2001-06-04 20:20:09
[Download RAW message or body]

#if Dirk Mueller
> the limit can be reduced immediately. however, the real solution seems
> to be some pipelining support, at least for kio_http. Still, with our
> relatively simple architecture this will introduce a lot of overhead,
> although it could be useful for other protocols as well..

In what way does this introduce overhead ?

> > As said above, it should be maximal two connections to the same server.
> 
> per browser window ? per user ? per session ? per host ?
> 
> the first one would be relatively simple to do. 

According to the RFC, 'A single-user client SHOULD maintain AT MOST 2
connections,' so user or client... probably either is OK, I would say.

I say this based on the assumption that if you have two browser windows
open on the same host, a lot of the images from a page will be only
requested once (another assumption - that if a request is in progress,
kio_http will not create another connection and request the same
resource) and then the browser window that gets the resource last
will get it from local cache.

There is, however, one small issue with this. The current default
'keep cache in sync' mode means that kio_http opens a connection
for just about everything, using 'If-Modified-Since' to see if it
needs to update.

While this doesn't use much bandwidth, it does require building a TCP
connection, so we may be seeing pages load slower than we would like
due to the time taken to negotiate new connections just to check
if the cache is in sync.

With pipelining, at least the time taken to negotiate a new connection
is gone, but there's still the time you have to wait for the replies
saying 'unmodified.'

> > Because of the http specs? Because opening 20 connections to one
> > host thrashes the server if every client does it.
> 
> Bah. there are still people out there using stoneage pre-forking servers 
> like apache ? ;)

I like a nice select() model. That's what kpf uses.

It's faster than Apache, believe it or not. Zeus and thttpd, the fastest
web servers around, use this model. kpf isn't that far behind thttpd.

The main reason kpf isn't as fast as thttpd is that I'm avoiding using
system-specific stuff like sendfile, TCP_CORK, kqueue etc. I want to
keep this thing portable, being a KDE app and all. #ifdef makes me
sick :)

Rik

[prev in list] [next in list] [prev in thread] [next in thread]