Date: Tue, 14 Aug 2001 18:41:56 -0400 From: Zach Brown <zab@zabbo.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: "Daniel M. Eischen" <eischen@vigrid.com>, Jonathan Chen <jon@FreeBSD.ORG>, hackers@FreeBSD.ORG Subject: Re: pthreads and poll() Message-ID: <20010814184156.A4825@erasmus.off.net> In-Reply-To: <3B79916D.FE1342E2@mindspring.com>; from tlambert2@mindspring.com on Tue, Aug 14, 2001 at 02:00:29PM -0700 References: <20010813120455.A63309@enterprise.spock.org> <3B780BFC.F2BA0A9B@vigrid.com> <3B79916D.FE1342E2@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[pulls out his dead horse..] > > one thread would wake up. The mistake in your sample seems to be that > > you're having all threads block on the same fd. Why? > > Probably he has a bunch of daemons waiting around for work to > do (e.g. HTTP daemons all listening for connections to accept > on the same fd). Lot's of applications could use this model > to get a performance boost. I have yet to see a 'thundering accept()' actually shown to be a meaningful performance problem. Are there more than two significant situations here? a) you have lots of idle servers waiting for work on an fd. it arrives, they all wake up, only to find that one of them gets to do real work. Who cares? you were idle. you had time to kill. The time when this wouldn't be acceptable would be if there were _very_ tight response time constraints. b) you're under load. your servers are off doing work under that load. you rarely see a significant number of them waiting for new work at the same time. wakeups (or scheduling) don't make up a meaningful percentage of the real work (io, networking, app data crunching, etc) that is being done. "b)" was the case at the zdnet benchmarks, though people ran around screaming things about thundering accept()s apaches when not a one of them had profiling runs in front of them :) I'm not saying that wake-one isn't a fine idea, I just keep seeing references to the mystical thundering accept() wakeup problem and its solution that brings better performance. I keep asking when people mention it and no one has been able to show this to be the case based on numbers. Am I insane? - z 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?20010814184156.A4825>