Date: Mon, 26 Jul 1999 17:04:00 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: aron@cs.rice.edu (Mohit Aron) Cc: freebsd-net@FreeBSD.ORG, druschel@cs.rice.edu Subject: Re: FreeBSD tuning for webserver performance Message-ID: <199907261504.RAA00474@labinfo.iet.unipi.it> In-Reply-To: <199907261510.KAA20768@cs.rice.edu> from "Mohit Aron" at Jul 26, 99 10:10:12 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907261504.RAA00474>