Date: Sat, 21 Apr 2001 07:48:11 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Zach Brown <zab@zabbo.net> Cc: Jef Poskanzer <jef@acme.com>, hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010421074811.O1790@fw.wintelcom.net> In-Reply-To: <20010421094738.B7494@erasmus.off.net>; from zab@zabbo.net on Sat, Apr 21, 2001 at 09:47:38AM -0400 References: <200104201611.JAA95537@bomb.acme.com> <20010420093349.X1790@fw.wintelcom.net> <20010421094738.B7494@erasmus.off.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Zach Brown <zab@zabbo.net> [010421 06:47] wrote: > [apologies for missing the original post and replying to a reply..] > > > > - A round-robin token-passing scheme to determine which process gets > > > to do the accept(). Turns out it's very bad to just have all the > > > processes do an accept(), since every time there's a new connection > > > *all* the processes wake up. The context switches totally kill > > > performance. But a properly tuned round-robin scheme works great. > > In my apache tuning adventures, including the insanity at the zd mindcraft > tests, I've never seen accept() hurding be a real measurable problem for > the simple reason that when you're under load your waiters aren't waiting > in accept(), they're off doing work. The only time this actually occurs > is when you're entirely idle and get a new connection. > > or so the numbers have lead me to beleive. Its still an annoying > design, but has someone come up with real numbers to show that accept() > hurding is a problem for waiters that do real work after accept() ? Accept herding isn't a problem under FreeBSD because the kernel doesn't allow it to happen. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010421074811.O1790>