On Tue, Nov 10, 2009 at 11:14, Akins, Brian <[email protected]> wrote: > On 11/9/09 3:08 PM, "Greg Stein" <[email protected]> wrote: > >> 2) If you have 10,000 client connections, and some number of sockets >> in the system ready for read/write... how do you quickly determine >> *which* buckets to poll to get those sockets processed? You don't want >> to poll 9999 idle connections/buckets if only one is ready for >> read/write. > > Epoll/kqueue/etc. Takes care of that for you.
Sorry. I wasn't clear. You have 10k buckets representing the response for 10k clients. The core loop reads the response from the bucket, and writes that to the network. Now. A client socket wakes up as writable. I think it is pretty easy to say "read THAT bucket" to get data for writing. Consider the scenario where one of those responses is proxied -- it is arriving from a backend origin server. That underlying read-socket is stuffed into the core loop. When that read-socket becomes available for reading, *which* client response bucket do you start reading from? And what happens if the client socket is not writable? You could just zip thru the 10k response buckets and poll each one for data to read, and the serf design states that the underlying read-socket *will* get read. But you've gotta do a lot of polling to get there. I think that will be an interesting problem to solve. I believe it would be something like this: Consider when a request arrives. The core looks at the Request-URI and the Headers. From these inputs, it determines the appropriate response. In this case, that response is identified by a bucket, configured with those inputs. (and somewhere in here, any Request-Body is managed; but ignore that for now) As that response bucket is constructed, along with all interior/nested buckets, that construction can say "I've got an FD here. Please add this to the core loop." The FD would be added, and would then be associated with the response bucket, so we know which to read when the FD wakes up. Cheers, -g
