... > > AOLserver is ideally suited to the majority of server tasks. About the > > only shortcoming which comes to mind is that conn threads are required > > to do blocking writes. But fixing that would be of benefit to the HTTP > > processing side too. > > So, we want reader threads and separate writer threads now, too? > Exactly how many free-range threads do we want roaming the server > prairie, here?
You don't need reader threads and writer threads. If input and output both use event-driven, non-blocking I/O, you can use one thread to do both, or one thread per CPU, like TUX. IMO it is not scalable to use connection servicing threads to spool output when the size of the output exceeds the socket buffer capacity. Doing I/O with non-blocking, event-driven threads also helps prevent DOS attacks. The trade-off is in memory usage: when a connection service thread does an ns_return, and the output exceeds the socket buffer size, you need to hang onto the buffer in memory somewhere while it is spooled by the HTTP I/O driver. The advantage is that the connection service thread can be off handling another request, but there is also a new resource to manage: spooled output buffers. Threads are usually a more scarce resource on a server compared to memory and socket connections, so IMO it's better to use the more plentiful resources to handle load/capacity issues. On a busy server, it would be easy to store 1000 spooled output buffers, each one being 100K. That's only 100MB of memory, which is nothing for modern high-end systems. However, running 1000 connection threads to service this same load doesn't seem as reasonable to me. Jim -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
