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]