Gustaf Neumann wrote: > 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.
It's somewhat similar to running 'ab' with a high concurrency (500 in this case). siege I've always gotten frustrated with. I've often found the need to write my own testing scripts for stuff like this, because the standards don't do what I want. ab is a good example; it will tell you simply and easily that your server can handle 100 requests/second. But since it waits for each request to finish before sending the next one, it won't tell you and can't simulate what happens when requests actually arrive faster than the server can handle them. > 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. I have a different solution which seems simpler, but I'm not sure if it has non-obvious implications. What I did is to check when the conn thread exits if it exited because it hit maxconns and there are still conections queued, and if so spawn a replacement thread before exiting. The subtlety I'm concerned about is that this changes the parent of a conn thread from the driver thread to a no-longer-existing conn thread. I don't think this is a problem, because conn threads aren't joined by the driver thread, they're joined by other conn threads (or the main thread on server shutdown). But I'm not positive, so I haven't checked in my changes. -J ------------------------------------------------------------------------------ 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
