On 12/12/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
I agree, to many knobs but hey, postgresql has it also and they always had such questions of how many bufers ineed to allocate, how much memory for sort, for temp. They got tired and on install now it tries to detect what is possible and set appropriate settings. but the knobs are still there for advanced usage. Having no knobs will require to be right about tuning for every possible machine or environment is not realistic. But defaults should be pretty well optimized with clear documentation how to tune, that is for sure.
"Knobs!" or "No Knobs!" is a false dichotomy. We need the appropriate number of knobs. Now in this case, you tested the acceptsize knob, found that if you turn it up there's an improvement, and if you leave it free to float all the way up it hurts nothing. You discovered that there's one correct setting: on. Or at least, you have no evidence to suggest when you ever would turn it down. Well done! Job sorted. Do random knobs facilitate advanced usage? They do not! Multiply the number of knobs together to come up a really large number -- the knobbage -- which you just ain't gonna have time to ever test. It's tough enough with all the genuine knob options. Don't be making it knobbier with sorta-kinda-maybe-someday knobs! And I think we should be keeping in mind, where we can, not just options and correct defaults, but self tuning.
Still i think even non-realistic tests are better than not having them at all, even when comparing .adp with .tcl performance i can see that file.tcl needs optimization. So, i believe benchmarks are good:-))
I tottally agree. I only mentioned it because of the conclusion you came to. Gotta be carefull there.
readahead is used to define when to spool uploaded content into file, nothing esle, once driver sees more than readahead it start spooling it. bufsize is how many bytes to read, both seems pretty clear but why that situation occurs i still have no idea.
So, what if readahead > bufsize, what does that mean? When we read-ahead, we read directly into the buffer. If the buffer is read-ahead sized, no point reading in smaller than neccessary bufsize chunks. What if readahead < bufsize? Does it mean the buffer will never be fully filled? What kind of sense does that make. Reading nsd/driver.c, it's really not obvious what's going on.
Stephen Deasey wrote: > 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. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > naviserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office [EMAIL PROTECTED] http://www.crystalballinc.com/vlad/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
