On Tue, 2004-08-17 at 10:04, Dossy Shiobara wrote: > On 2004.08.17, Stephen Deasey <[EMAIL PROTECTED]> wrote: > > This isn't true. In AOLserver, once a request has completed the conn is > > returned to the driver thread for keepalive. It's monitored in a > > non-blocking fashion until either it times out or the client makes > > another request. In the meantime, the conn thread which just completed > > is free to service other requests. > > Um, what about protocols that requires the server to maintain state with > the connection? If the thread servicing the connection gets returned to > the pool, doesn't the state go along with it?
State is stored in session local storage. This is just like conn and thread local storage, but the data lifetime is from socket connect to socket disconnect. The example server illustrates this. > > This makes it possible to have 1000 concurrent connections serviced by a > > pool of just 10 threads -- at any one time most of the connections will > > be momentarily idle. This benefits memory usage and context switch > > overhead. > > This is only desirable for stateless protocols, like HTTP. It's highly desirable for stateful protocols too. The inactivity timeout for POP3 is 10 minutes, so potentially your thread+interp could be kept tied up for that period of time. My email client (IMAP) checks for new messages every 3 minutes -- it doesn't disconnect in between. The request-response-pause pattern is common to many protocols. > > This is one of the major architectural benefits AOLserver has over > > something like Apache. In the Apache model, processes take turns > > listening for connections. When a connection arrives, the process > > switches roles from a listener to a worker and processes the > > connection. The worker processes the connection to completion, > > including idle wait time due to keepalive. > > True, for stateless protocols like HTTP, the AOLserver model is > superior. For stateful protocols, this may not work so well. > > > 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? > > > > Of course, we're both only speculating here. > > > > Speak for yourself! > > Show me your measurements. And I'm not talking 36D-28-34, either. I think the burden of proof lies with you. A non-HTTP server implemented with the proposed Ns_ParseProc interface is exactly the same architecturally as stock AOLserver. If you think you can rewrite it all in Tcl and make it faster, I'd be interested to see that. I don't think you can do it. -- 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.
