On 12/12/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
When i started this i did not want to be the fastest, i wanted to see where we stand, even if it would turn out that we are the slowest, that would mean it requires some work in optimization area. I am not looking around for the fastest toolkit to switch, but as i told i caught myself thinking that we are faster than apache/php and it turned out not true, at least it requires special tuning or producing specific Tcl code to be as fast as others. Stephen Deasey wrote: > > This planet..?
Sorry, forgot the smiley face on the end of that one... :-) Re the tuning thing, I think that's a bug. If you need to write some specific style of oddball Tcl or twiddle a dozen magic knobs then chances are you're going to get it wrong. It's no good having potential if you're not likely to achieve it. That's why I think you should drop the acceptsize knob :-) You've proved that having no upper limit does not harm performance, and gains all there is to gain by setting it to > 1. Hey, if you do some more testing and find out it's really useful to set it > 1 but < OS backlog, well sure. But as of now that isn't the case and it's just another thing to get wrong. It's a pretty fine distinction. You can tune the rate of acceptance with the OS backlog. Multiple knobs invite errors. I'm pretty sure the long standing bug with infinite loops in the driver thread depending on some odd combination of input size and buffer size is due to the mixup between 'buffersize' and 'readahead'. There's one too many knobs there. What's the difference between these two parameters? There's really a lot we could do to improve things here. Have you ever noticed a common question on the AOLserver mailing list is "how many threads should I have" or "how many conns should I have" or "what size should my database pool be"? The answer is always: it depends! Which is sorta-kinda strictly true, it depends on a lot of things. But it's not very helpfull! So the person asks again, for anything, please, what are y'all running?! If you look at the ammount of variables in just this small, artificial test you've been running here, and the number of people chiming in with suggestions, and the improvement you got from "oh dear it's slower than Apache" to 6000 ass-kicking request per second, I'd argue that although technically speaking, "it depends" is the right answer, it's so unlikely you'll have the time to lab test your set-up accurately that it's really the wrong answer. Won't happen. I'd go further. The code you write makes a difference, and that's under your controll, but your site traffic is not. What if your forum is slashdotted, or it's the week before christmas and your checkout is smoked? You don't controll, and aften can't predict, which resources of your site will be in most demand. Threads, db handles, cache memory? So not only is it unlikely that you'll correctly tune the magic knobs due to lack of time or knowledge, it just can't be done. But there's still a lot of tuning knobs. We should fix that.
