On Tue, 2004-08-17 at 08:07, Dossy Shiobara wrote: > On 2004.08.17, Stephen Deasey <[EMAIL PROTECTED]> wrote:
... > > Each of your connection threads and all it's resources are committed for > > the life of the connection. It will remain committed until the client > > disconnects. > > This will be true regardless of the implementation (C vs. Tcl) as it's a > requirement of the TiVo beacon protocol -- clients maintain persistent > connections to the server. 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. 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 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. > I disagree. SMTP and IMAP are toy servers with regard to complexity, > just as the TiVo server is. They are all very simple protocols. The > challenge is scalability -- the assumption here is that a pure Tcl > solution will not perform well enough to scale compared to the C > solution. It's only an assumption. As you say, parsing is the least difficult part of creating a scalable server. Which is why I added a hook to implement just that, so that you can take advantage of all the AOLserver scalability features. > My hunch is that empirical evidence will show that none of the > "features" of AOLserver will make the C solution perform exceptionally > better than a pure Tcl solution. If you're going to implement in C for > performance, implement something tailored to solving the problem > specifically -- that will be the only way to really get the performance > required. 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. > Of course, we're both only speculating here. Speak for yourself! -- 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.
