From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Stephen C. Harris" Message-Id: <200007121339.IAA10050@sch1.NCTR.FDA.GOV> Date: Wed, 12 Jul 2000 13:39:06 +0000 To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: Any significant gotchas? In-Reply-To: <10007111441.ZM757223@marvin> MIME-Version: 1.0 Content-Type: text/plain Topicbox-Message-UUID: d8b19c80-eac8-11e9-9e20-41e7f4b1d025 "Tom Duff" wrote: > What application needs to do select on 1000s of file descriptors? I was thinking web serving and IRC. Linux for one has benefited greatly as a web server performance-wise just recently, now that it has a good async-io implementation. ( 3 x the performance of W2K on SpecWeb99 !). When not many descriptors have data available, signals deliver information about which descriptors are ready (so you don't have to scan the long list of file descriptors). On the other hand, when lots of descriptors are ready, you get a "signal-queue full" signal and can fall back to poll()/select() which will reap lots of ready descriptors (gauranteeing the full descriptor list is worth scanning). I don't know how light-weight Plan9 processes are, but I assume each gets its own stack and consumes some kernal memory. In Linux (for comparison) that's 8k (stack) + 20k kernal (at least) per connection, which adds up quickly when you start talking about large numbers of connections ( ~ 500 MB for 15000 connections I think was a lower bound for a Linux estimate ). I'm not saying this is the right system for plan9, I'm just noting that it has apparently helped traditional UNIX in web-server performance a great deal. I'm sure Plan9 could do something cleaner.