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.
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:-))
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.
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/
