Actually that is a good point. I hadn't thought of that. I have some services that I wrote a long time ago that take a -o options setting, which is for those odd options that are rarely used, but occassionaly needed for fine-tuning...
so I would have something like: webservice -v -a 127.0.0.1 -p 14077 -o "pre-fetch=1,fetch-fail-delay=15,lib-preload=0" If you're interested I could dig out the old code that does this... or might not be difficult to start from scratch. That might be a good way of handling these kinds of rarely used settings. On Tue, Mar 17, 2009 at 3:46 AM, Dustin <[email protected]> wrote: > > > Thanks for all the feedback. I was thinking that a compile-time > option might be good to avoid eating up the precious getopt space for > things that are rarely used, but this is pretty unanimous. :) > > On Mar 16, 5:38 am, Trond Norbye <[email protected]> wrote: > > Dustin wrote: > > > Chris Goffinet removed another magic number by making the TCP listen > > > backlog runtime configurable here: > > > > > > http://github.com/lenn0x/memcached/commit/7d010a855ecccf4960fce4ffa4b... > > > > > Before this change, memcached had a hard-coded backlog of 1024. > > > It's possible to exceed 1024 with a connection burst from a large > > > number of clients at which point some clients will see connection > > > refused. Some such large installations have pushed this up to 4096 or > > > so, while others might appreciate saving some kernel memory by keeping > > > it low and having fewer bursty connection bringups. > > > > > Does anyone have an opinion on this? My only question is whether it > > > should be a compile-time option or a runtime option. > > > > I would prefer to keep the compile-time options at a minimum, because it > > makes it difficult to provide a binary version.... > > > > Btw. If you apply this patch please add the -b to the list of options > > in http://code.google.com/p/memcached/issues/detail?id=28 > > > > Cheers, > > > > Trond > -- "Be excellent to each other"
