On 11.10.12 21:01, Jeff Rogers wrote: > Gustaf Neumann wrote: >> Am 11.10.12 19:42, schrieb Jeff Rogers: >>> I'll clean up my testcases and add them. >> great! > Hrm. I have a completely reproducible case, good test case. The frequency in which the script sends new requests is much higher than from programs like "siege" and the like, since the tcl script just fires locally the http-requests asynchronously without waiting for the replies.
>> i looked a little into the request burst problem and got some better >> understanding. The problem actually happens when the server runs >> out of threads and more than maxconn requests arrive constantly >> in the timespan of a thread creation. > I think it's when many requests arrive in less than the timespan of a > thread lifetime, not just creation. You are right, not only "my" thread serialization can cause the problem, but it can happen as well when e.g. maxthreads are already running, and a sudden burst of requests is dropping in, and than there is silence. When the sum of the remaining lifespan of the connection threads is less than the number of queued requests, there will be threads left in the queue when the last connection thread exits. I have done some refactoring and added a liveliness test to the driver. it is set up currently with a timeout of 1 second. -gustaf neumann ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
