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

"Jay West" <[email protected]> Tue, 26 Nov 2002 11:59:58 -0600
Newsgroups gmane.comp.apache.mod-log-spread.user
Message-ID <[email protected]>
----- 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]