I would guess there are a number of problems. First is that the number of threads is way too high compared to the conns per thread. you have a 5:1 ratio, I wouldn't go with anything less than 1:1, and 1:10 would be even better.
So 10 threads, 100 conns per thread before exit. Another problem you can't solve is the queue operation. In the cvs head version, thread wake-up is handled by using Ns_CondSignal instead of Ns_CondBroadcast. Signal only wakes up one thread at a time, whereas Broadcast gives every thread a chance to restart execution. In practice what happens is that the thread which called Signal usually gets woken up, so it starts executing again. What can happen is that slow requests get stuck sleeping while one thread grabs quick requests. Essentially you have on thread working the queue. It is then possible for this thread to exit after serving all requests, just as the traffic dies down. You end up with threads waiting to wake up, the driver waiting for new requests and somehow nothing happening. One thing you could do, just for testing if requests are still being processed prior to going into the queue, is to register a prequeue filter. Register it to an exact url which will never be called under normal conditions. When your server gets stuck you can visit the url and see if it logs something (Just use the prequeue filter to issue an ns_log and return filter_ok). But note: never use a prequeue filter in Tcl for anything else. It causes a massive memory leak, probably because a Tcl interp is created and never destroyed. You get about a 1 virtual server sized memory leak per request if your request matches a prequeue filter. If something is logged, it means that the request was processed by the driver thread and probably put into the queue to wait for a free conn thread. If not, it means that something is blocking the driver thread, or maybe something else is going on. tom jackson On Sun, 2009-05-03 at 13:47 -0300, Eduardo Santos wrote: > Just another guess: do you have anything between AOLServer and the > connections, such as Apache proxy and other things? Most performance > problems in AOLServer we've seen are related to the environment, no to > the AOLServer itself. > > 2009/5/1 Dossy Shiobara <[email protected]> > On 5/1/09 6:17 PM, William Scott Jordan wrote: > I think it's worth noting that when AOLserver stops > accepting > connections, nslog doesn't log any of the failed > requests. New > connections seem to just be rejected outright. > > > Do you have nscp enabled? Is the control port still > responsive to commands? Can you capture the output of "join > [ns_info threads] \n" from the control port once AOLserver > stops accepting connections? > > > -- > Dossy Shiobara | [email protected] | > http://dossy.org/ > Panoptic Computer Network | http://panoptic.com/ > "He realized the fastest way to change is to laugh at your > own > folly -- then you can let go and quickly move on." (p. 70) > > > -- > > > 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. > > > > -- > 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. > > -- 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.
