Re: Fw: Re[2]: problem with error_log_spread.pl

There are plenty of other sophisticated pieces of software that let you 
set a listen queue length.  Apache, for example.  I don't see why making 
this configurable by the user is an issue at all.

Choice is good.


Jay West wrote:

>----- Original Message -----
>From: "Jay West" <[email protected]>
>To: "Yair Amir" <[email protected]>
>Sent: Tuesday, November 26, 2002 11:58 AM
>Subject: Re: Re[2]: [mls-users] problem with error_log_spread.pl
>
>
>>Yair wrote....
>>
>>>What I really wanted to understand is what is the drawback of make it,
>>>say 100. What is the cost associated with making it 100?
>>>If there is no cost, why not do it? If the cost is maintaining a few
>>>bytes per each potential concurrent connection request, a few hundred
>>>bytes are not an issue, are they?
>>>
>>Simple reason... OS kernel normally limits this, and that's where it
>>
>should
>
>>be managed, not in spread. FreeBSD is nice enough that if you set it too
>>high on a program request, it silently uses it's own max limit. This is a
>>good thing(tm) IHMO. But I would think that you can't bank on all OS's
>>behaving nicely about this. So if you set it hardcoded to 100, what will
>>happen on an OS that limits it to 50 other than FreeBSD? A panic? I have
>>
>no
>
>>idea, and we can't assume that what a given platform does with this today,
>>will be the same way it handles it in future releases.
>>
>>If there is no penalty other than a few bytes of memory, perhaps
>>programatically check at runtime what the system limit is by interrogating
>>the kernel state value (sysctl), and set the listen parameter to this max
>>(at runtime, not compile time). That way, if some need arises where the
>>built in kernel state value isn't enough, most administrators will know
>>
>what
>
>>to change, and where to change it, and it's only in one place.
>>
>>On the other hand, if there are some penalties with setting the value high
>>without real need, then by all means, a spread config parameter where the
>>user can specify it is a good thing.
>>
>>Wait - after digging further.... I noticed that on freebsd if you call
>>listen with the backlog queue specification as a negative number, it will
>>use the current kernel state value (kern.somaxconn). Nice! But again, one
>>can't rely on other platforms to do the same.
>>
>>Here's my vote - if most other platforms support backlog of -1
>>
>(negative)...
>
>>have spread by default use -1 unless they specify a config file parameter.
>>
>I
>
>>guess what guides my view is I hate having two places to change
>>
>something -
>
>>the kernel state value AND the spread config file.
>>
>>Just some random thoughts.
>>
>>Jay West
>>
>>
>
>---
>[This E-mail scanned for viruses by Declude Virus]
>
>
>_______________________________________________
>mls-users mailing list
>[email protected]
>http://lists.backhand.org/mailman/listinfo/mls-users
>