From owner-freebsd-net Mon Jul 26 10:41:50 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id B4CE114D96 for ; Mon, 26 Jul 1999 10:41:45 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA00474; Mon, 26 Jul 1999 17:04:00 +0200 From: Luigi Rizzo Message-Id: <199907261504.RAA00474@labinfo.iet.unipi.it> Subject: Re: FreeBSD tuning for webserver performance To: aron@cs.rice.edu (Mohit Aron) Date: Mon, 26 Jul 1999 17:04:00 +0200 (MET DST) Cc: freebsd-net@FreeBSD.ORG, druschel@cs.rice.edu In-Reply-To: <199907261510.KAA20768@cs.rice.edu> from "Mohit Aron" at Jul 26, 99 10:10:12 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1665 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I measured it in two ways - first by instrumenting the code path by using the > cycle counter. This gave values of 50 usec when the SYN was received repeatedly > (i.e. everything's in the cache) and a value of 150 usec when the SYN was ok, thanks. ... > > Keeping queues short is always useful -- even in the case of your > > busy web server, just to give one example, you might cause your > > SYN|ACK for new connections incur a large delay just because you > > have a huge number of data packets queued for delivery. > > I accept your argument but I think short driver output queues might be > useful in very limited number of cases. These are when the bottleneck in the > path to the clients occurs at the driver. I would imagine that in most cases > the bottleneck occurs at some external router (which usually have large > queues). usually backbone routers have (or try, or ought to) some active queue management techniques such as RED or fair queueing variants so that per-flow queues are kept short. Try to flood-ping some site behind a bottleneck while you run a regular ping to the same site with a separate connection, and you'll see that in many cases the delay does not increase a lot -- you can even compute the queue size with this technique using different packet sizes. > > unfortunately fixing TCP like you suggest, while desirable is not > > easy because there is not a fine-grained timer to use. > > I have a paper submitted on how to implement very fine-grained timers in an OS > with very low overhead. Rate-based pacing is one of the goals of these timers. > Hopefully it'll get published soon. :) good luck then :) cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message