Date: Sat, 5 Apr 1997 22:02:54 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: David Greenman <dg@root.com> Cc: FreeBSD-hackers <FreeBSD-hackers@freebsd.org> Subject: Re: apache like preforking apps and high loads Message-ID: <Pine.BSF.3.95.970405215324.19091W-100000@alive.znep.com> In-Reply-To: <199704040000.QAA05674@root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Apr 1997, David Greenman wrote: > >On Thu, 3 Apr 1997, David Greenman wrote: > > > >> >When looking at Apacha like applications, one often sees extermely high > >> >load averages. Apache preforks a number of processes that all block > >> >on accept(). When a request comes in, all process are woken up and the > >> >scheduler chooses one of the now runnable processes taht will succeed in > >> >the accept(). The other go back to sleep. > >> > >> Not any more. I changed this a few days ago. Now only one process is > >> woken up. > > > >Looking at these changes and the other code around them, it appears to me > >like the net effect is that processes are added to the tail of the queue > >when they block on accept() and removed from (near) the head with > >wakeup_one. Am I reading this right, or am I getting my queue ends mixed > >up somewhere? > > You have it right, and that is the way it needs to work. I don't know > how Apache does it's # processes load balancing, but fairness can be important > in general. Of course; lots of things rely on that behavior and it can't really be changed by default. Apache's method of load balancing over processes is to not bother; just has all of them blocking in accept[1] and whatever one gets it (ie. what the kernel decides) gets it. > > >For code that does similar things to what Apache does, it would be far > >better to treat it as a stack and have wakeup_one() remove from the tail > >since you want the same processes to serve as many requests as possible. > >In the grand scheme of things it may be a bad idea to have wakeup_one() > >behave this way, but it looks like it would be useful in this case. > > On the x86 and most other architectures, the cache is of physical memory > and the majority of the Apache code is in shared pages. There isn't any > significant difference in terms of cache effects whether you wake the same > process all the time or you wake different processes. The code yes, but obviously not most of the data which should be less significant, but possibly still of some importance. I have done some testing on these things and it did appear that something was effecting a noticable slowdown when there were more children handling requests; it is true that there are other things impacting this and I was not looking at this from the OS level but from the level of the Apache code. I'll have to look at this again when I'm doing some testing and actually try the change. Would people consider it too big of a hack to add an option (setsockopt()?) to allow a process to override the default behavior on a socket, provided it actually has a useful performance impact? [1] On non-broken platforms it works this way; an amazingly large number of platforms can't handle multiple processes in accept() on the same socket at the same time, so a lockfile is used to control who accepts()s at any time.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970405215324.19091W-100000>