You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2000/07/09 20:18:01 UTC
Remove prefork MPM.
I have tested the new mpmt MPM, and it emulates the prefork MPM pretty
much perfectly as near as I can tell. It needs optimizing, and the
#defines need to be done a bit better, but it works just fine AFAICT. I
would like to remove the prefork MPM Tuesday. Does anybody have a problem
with that?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Remove prefork MPM.
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> and prefork needs to go away.
Um, I don't accept this thesis at all. -1 on removing prefork
until I see an acceptable explanation..
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: Remove prefork MPM.
Posted by rb...@covalent.net.
On Tue, 11 Jul 2000, Greg Ames wrote:
> Combining Dexter and mpmt_pthread is a great idea. But I think removing
> prefork is premature.
>
> rbb@covalent.net wrote:
> >
> > I have tested the new mpmt MPM, and it emulates the prefork MPM pretty
> > much perfectly as near as I can tell. It needs optimizing, and the
>
> Huh? If it emulates prefork perfectly, why would it need optimizing?
Because it needs to remove the pthread calls, and everything else you are
complaining about below. Yes, it emulates prefork. It preforks the
required number of servers, and spawns new ones when they are busy. It
needs a new #define and a couple of new #ifdefs. If nobody else beats me
to it, I'll get to it sooner or later. Having the same function in the
server three times is idiotic, and prefork needs to go away.
Ryan
>
> > #defines need to be done a bit better, but it works just fine AFAICT. I
> > would like to remove the prefork MPM Tuesday. Does anybody have a problem
> > with that?
> >
>
> A quick look at the code shows me that there's no code path that avoids
> the pthread mutexes or ap_poll. This is going to cause increased path
> length and worse scalability on platforms like Linux, and probably
> FreeBSD, that have relatively light weight processes. I suspect the
> majority of the current Apache users would see a drop in performance if
> they upgraded to 2.0 with mpmt.
>
> When mpmt performs like prefork on Linux and FreeBSD, then I'm all for
> it.
>
> Greg
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Remove prefork MPM.
Posted by Greg Ames <gr...@raleigh.ibm.com>.
Combining Dexter and mpmt_pthread is a great idea. But I think removing
prefork is premature.
rbb@covalent.net wrote:
>
> I have tested the new mpmt MPM, and it emulates the prefork MPM pretty
> much perfectly as near as I can tell. It needs optimizing, and the
Huh? If it emulates prefork perfectly, why would it need optimizing?
> #defines need to be done a bit better, but it works just fine AFAICT. I
> would like to remove the prefork MPM Tuesday. Does anybody have a problem
> with that?
>
A quick look at the code shows me that there's no code path that avoids
the pthread mutexes or ap_poll. This is going to cause increased path
length and worse scalability on platforms like Linux, and probably
FreeBSD, that have relatively light weight processes. I suspect the
majority of the current Apache users would see a drop in performance if
they upgraded to 2.0 with mpmt.
When mpmt performs like prefork on Linux and FreeBSD, then I'm all for
it.
Greg
Re: Remove prefork MPM.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jul 11, 2000 at 01:42:08PM -0700, rbb@covalent.net wrote:
> On Tue, 11 Jul 2000, Greg Stein wrote:
> > On Tue, Jul 11, 2000 at 04:25:16PM -0400, Paul J. Reder wrote:
> > > rbb@covalent.net wrote:
> > > > There is a lot of stuff we can do to make more of this code common, but it
> > > > will take more time.
> > >
> > > Then I would suggest that we leave the existing mpms around at least until
> > > mpmt has been cleaned up and optimized. If we have too much main line code
> > > that needs to be cleaned up and optimized, I fear we are going to end up
> > > with an unusable server.
> >
> > Agreed. Especially on the main line (optional functionality like modules
> > isn't as big of a deal).
> >
> > I've been making checkins to mpmt_pthread to keep it working while Ryan
> > bangs mpm_common around. Dunno if prefork or dexter work any more, though.
>
> "ALPHA"
That isn't an excuse to break the server on *purpose*. Breaking it for a
short period is fine, but saying "being broken will incent somebody to fix
it" doesn't sound like a good plan to me. I'd rather not rely on people just
happening to have enough time and incentive, instead of measured steps and
progress that keeps the server running.
When mpmt was first added and was selected for my server's MPM, the server
flat out didn't work. It would start and then exit. Fine. I fixed it by
going back to the old MPM.
But to suggest that checking in known-broken code is acceptable... I just
don't buy it.
> dexter still works. mpmt_pthread still works. prefork doesn't. I am not
> going to fix prefork, even though it is most likely a relatively easy
> thing to do.
Didn't say you had to. I'm keeping mpmt_pthread working because I know it
has worked in the past, so I use that rather than an still-in-process MPM.
> I also don't like the implication that I am not being
> relatively careful with mpmt_pthread and dexter while trying to remove
> common code.
Did say that, nor did I intend to imply it. No need to be defensive. My
point was that I'd try to keep mpmt_pthread working; somebody else will need
to pay attention to the others if they break during the changes to
mpm_common or the config scripts.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Remove prefork MPM.
Posted by rb...@covalent.net.
On Tue, 11 Jul 2000, Greg Stein wrote:
> On Tue, Jul 11, 2000 at 04:25:16PM -0400, Paul J. Reder wrote:
> > rbb@covalent.net wrote:
> > > There is a lot of stuff we can do to make more of this code common, but it
> > > will take more time.
> >
> > Then I would suggest that we leave the existing mpms around at least until
> > mpmt has been cleaned up and optimized. If we have too much main line code
> > that needs to be cleaned up and optimized, I fear we are going to end up
> > with an unusable server.
>
> Agreed. Especially on the main line (optional functionality like modules
> isn't as big of a deal).
>
> I've been making checkins to mpmt_pthread to keep it working while Ryan
> bangs mpm_common around. Dunno if prefork or dexter work any more, though.
"ALPHA"
dexter still works. mpmt_pthread still works. prefork doesn't. I am not
going to fix prefork, even though it is most likely a relatively easy
thing to do. I also don't like the implication that I am not being
relatively careful with mpmt_pthread and dexter while trying to remove
common code.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Remove prefork MPM.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jul 11, 2000 at 04:25:16PM -0400, Paul J. Reder wrote:
> rbb@covalent.net wrote:
> > There is a lot of stuff we can do to make more of this code common, but it
> > will take more time.
>
> Then I would suggest that we leave the existing mpms around at least until
> mpmt has been cleaned up and optimized. If we have too much main line code
> that needs to be cleaned up and optimized, I fear we are going to end up
> with an unusable server.
Agreed. Especially on the main line (optional functionality like modules
isn't as big of a deal).
I've been making checkins to mpmt_pthread to keep it working while Ryan
bangs mpm_common around. Dunno if prefork or dexter work any more, though.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Remove prefork MPM.
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jul 12, 2000 at 10:10:43AM -0400, Rodent of Unusual Size wrote:
> rbb@covalent.net wrote:
> >
> > This is an ALPHA! We can clean and optimize in beta stage.
>
> As long as we don't delete working items that will need those
> 'optimisations' to replace. In other words, no deleting prefork
> until there's a replacement.
Unfortunately, the prefork MPM may already be broken. In an email from Joe
Orton, he said that he ran into problems with it and got stuck for a while.
Eventually, he saw the messages that it might be broken, so he used
something else.
But I agree with you: don't toss until a replacement is available.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Remove prefork MPM.
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> This is an ALPHA! We can clean and optimize in beta stage.
As long as we don't delete working items that will need those
'optimisations' to replace. In other words, no deleting prefork
until there's a replacement.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: Remove prefork MPM.
Posted by rb...@covalent.net.
On Tue, 11 Jul 2000, Bill Stoddard wrote:
> > It is smaller than the three other MPMs combined, although not by
> > much right now.
> >
> Heh, I had to read this twice. Damning praise?
I don't mind that the code isn't much smaller than the other three MPMs
combined. I really haven't tried to combine code yet. There are at least
three variables that can be made common, thus removing a lot of duplicated
code. Plus, there are at least four places where the #ifdefs surround
scoreboard stuff. If the scoreboard is made more abstract, all of that
code becomes common immediately.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Remove prefork MPM.
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
> It is smaller than the three other MPMs combined, although not by
> much right now.
>
Heh, I had to read this twice. Damning praise?
Re: Remove prefork MPM.
Posted by rb...@covalent.net.
This is an ALPHA! We can clean and optimize in beta stage. Since when
has getting optimized code been a requirement for an alpha? The code
works. It is smaller than the three other MPMs combined, although not by
much right now.
If we leave the other code in there, nobody tries to fix the smaller
solution to make it clean. If we rip out the MPMs that have duplicate
code, then we are forced to clean the one common MPM, and keep it clean.
Forget it. I'll clean that code over the next week, and then I'll remove
the other MPMs once everybody says its okay.
Ryan
On Tue, 11 Jul 2000, Paul J. Reder wrote:
> rbb@covalent.net wrote:
> > There is a lot of stuff we can do to make more of this code common, but it
> > will take more time.
>
> Then I would suggest that we leave the existing mpms around at least until
> mpmt has been cleaned up and optimized. If we have too much main line code
> that needs to be cleaned up and optimized, I fear we are going to end up
> with an unusable server.
>
> --
> Paul J. Reder
> -----------------------------------------------------------
> "The strength of the Constitution lies entirely in the determination of each
> citizen to defend it. Only if every single citizen feels duty bound to do
> his share in this defense are the constitutional rights secure."
> -- Albert Einstein
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Remove prefork MPM.
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
rbb@covalent.net wrote:
> There is a lot of stuff we can do to make more of this code common, but it
> will take more time.
Then I would suggest that we leave the existing mpms around at least until
mpmt has been cleaned up and optimized. If we have too much main line code
that needs to be cleaned up and optimized, I fear we are going to end up
with an unusable server.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Remove prefork MPM.
Posted by rb...@covalent.net.
I'm not touching mpmt.c anymore for the next day or two. Feel free to do
whatever you want in it.
Ryan
On Tue, 11 Jul 2000, Bill Stoddard wrote:
> If you can run the "unified" MPM in pure prefork mode (without relying on pthreads for
> anything) and keep the #ifdefs to a minimum, then I'm +1 on all of this. I pretty much
> agree with you that it is possible to reduce the #ifdefs with a little work.
>
> While you are monkeying with the MPMs, can you change MaxClients to MaxServers? The name
> 'MaxClients' is misleading in the context of the threaded MPMs. I would do it myself but I
> don't want to get in the way of your work.
>
> Bill
>
> > Take a look at the MPMs. All of the common code that doesn't require
> > global variables has been moved to mpm_common. If we move any more code
> > to mpm_common.c, we have to open up global variables, which I don't want
> > to do.
> >
> > Then, take a look at mpmt.c. It's a mess of #ifdefs. Now, take a closer
> > look. Most of those can go away with a little bit of elbow grease on the
> > code. Even the stuff that isn't common code within the Unix MPMs right
> > now, is mostly common concepts, it's just variable names or how the code
> > was written that is different.
> >
> > The scoreboard stuff is a HUGE part of the non-common code in mpmt.c. If
> > we can finish abstracting that stuff, a big part of the #ifdefs go away.
> >
> > There is a lot of stuff we can do to make more of this code common, but it
> > will take more time.
> >
> > Ryan
> >
> > On Tue, 11 Jul 2000, Greg Stein wrote:
> >
> > > On Tue, Jul 11, 2000 at 10:14:58AM -0700, rbb@covalent.net wrote:
> > > > On Tue, 11 Jul 2000, Rodent of Unusual Size wrote:
> > > >
> > > > > rbb@covalent.net wrote:
> > > > > >
> > > > > > I would like to remove the prefork MPM Tuesday. Does anybody have
> > > > > > a problem with that?
> > > > >
> > > > > Yep, I do. We need to keep a true prefork MPM around, not an
> > > > > emulated one that requires threads and thread locking.
> > > >
> > > > There is no reason to have as much duplicated code as the Unix MPMs
> > > > have. I can remove most of the duplicated code, but that requires opening
> > > > up a lot of static variables. The more duplicated code we have, the more
> > > > times we have to fix the same bug.
> > >
> > > Rather than jamming them all together, why not simply create more mpm_common
> > > functions? If they need state, then start passing around the data (instead
> > > of global variables). Or a context structure.
> > >
> > > > I am in the middle of fixing mpmt so that it doesn't require any of the
> > > > threads stuff. That is an optimization though, and it can wait for a day
> > > > or two.
> > >
> > > I fear that mpmt.c is going to become unmaintainable because of all the
> > > #ifdef code in there.
> > >
> > > Sharing code through mpm_common seems like the most appropriate solution.
> > >
> > > Cheers,
> > > -g
> > >
> > > --
> > > Greg Stein, http://www.lyra.org/
> > >
> >
> >
> > _______________________________________________________________________________
> > Ryan Bloom rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
> > -------------------------------------------------------------------------------
> >
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Remove prefork MPM.
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
If you can run the "unified" MPM in pure prefork mode (without relying on pthreads for
anything) and keep the #ifdefs to a minimum, then I'm +1 on all of this. I pretty much
agree with you that it is possible to reduce the #ifdefs with a little work.
While you are monkeying with the MPMs, can you change MaxClients to MaxServers? The name
'MaxClients' is misleading in the context of the threaded MPMs. I would do it myself but I
don't want to get in the way of your work.
Bill
> Take a look at the MPMs. All of the common code that doesn't require
> global variables has been moved to mpm_common. If we move any more code
> to mpm_common.c, we have to open up global variables, which I don't want
> to do.
>
> Then, take a look at mpmt.c. It's a mess of #ifdefs. Now, take a closer
> look. Most of those can go away with a little bit of elbow grease on the
> code. Even the stuff that isn't common code within the Unix MPMs right
> now, is mostly common concepts, it's just variable names or how the code
> was written that is different.
>
> The scoreboard stuff is a HUGE part of the non-common code in mpmt.c. If
> we can finish abstracting that stuff, a big part of the #ifdefs go away.
>
> There is a lot of stuff we can do to make more of this code common, but it
> will take more time.
>
> Ryan
>
> On Tue, 11 Jul 2000, Greg Stein wrote:
>
> > On Tue, Jul 11, 2000 at 10:14:58AM -0700, rbb@covalent.net wrote:
> > > On Tue, 11 Jul 2000, Rodent of Unusual Size wrote:
> > >
> > > > rbb@covalent.net wrote:
> > > > >
> > > > > I would like to remove the prefork MPM Tuesday. Does anybody have
> > > > > a problem with that?
> > > >
> > > > Yep, I do. We need to keep a true prefork MPM around, not an
> > > > emulated one that requires threads and thread locking.
> > >
> > > There is no reason to have as much duplicated code as the Unix MPMs
> > > have. I can remove most of the duplicated code, but that requires opening
> > > up a lot of static variables. The more duplicated code we have, the more
> > > times we have to fix the same bug.
> >
> > Rather than jamming them all together, why not simply create more mpm_common
> > functions? If they need state, then start passing around the data (instead
> > of global variables). Or a context structure.
> >
> > > I am in the middle of fixing mpmt so that it doesn't require any of the
> > > threads stuff. That is an optimization though, and it can wait for a day
> > > or two.
> >
> > I fear that mpmt.c is going to become unmaintainable because of all the
> > #ifdef code in there.
> >
> > Sharing code through mpm_common seems like the most appropriate solution.
> >
> > Cheers,
> > -g
> >
> > --
> > Greg Stein, http://www.lyra.org/
> >
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
Re: Remove prefork MPM.
Posted by rb...@covalent.net.
Take a look at the MPMs. All of the common code that doesn't require
global variables has been moved to mpm_common. If we move any more code
to mpm_common.c, we have to open up global variables, which I don't want
to do.
Then, take a look at mpmt.c. It's a mess of #ifdefs. Now, take a closer
look. Most of those can go away with a little bit of elbow grease on the
code. Even the stuff that isn't common code within the Unix MPMs right
now, is mostly common concepts, it's just variable names or how the code
was written that is different.
The scoreboard stuff is a HUGE part of the non-common code in mpmt.c. If
we can finish abstracting that stuff, a big part of the #ifdefs go away.
There is a lot of stuff we can do to make more of this code common, but it
will take more time.
Ryan
On Tue, 11 Jul 2000, Greg Stein wrote:
> On Tue, Jul 11, 2000 at 10:14:58AM -0700, rbb@covalent.net wrote:
> > On Tue, 11 Jul 2000, Rodent of Unusual Size wrote:
> >
> > > rbb@covalent.net wrote:
> > > >
> > > > I would like to remove the prefork MPM Tuesday. Does anybody have
> > > > a problem with that?
> > >
> > > Yep, I do. We need to keep a true prefork MPM around, not an
> > > emulated one that requires threads and thread locking.
> >
> > There is no reason to have as much duplicated code as the Unix MPMs
> > have. I can remove most of the duplicated code, but that requires opening
> > up a lot of static variables. The more duplicated code we have, the more
> > times we have to fix the same bug.
>
> Rather than jamming them all together, why not simply create more mpm_common
> functions? If they need state, then start passing around the data (instead
> of global variables). Or a context structure.
>
> > I am in the middle of fixing mpmt so that it doesn't require any of the
> > threads stuff. That is an optimization though, and it can wait for a day
> > or two.
>
> I fear that mpmt.c is going to become unmaintainable because of all the
> #ifdef code in there.
>
> Sharing code through mpm_common seems like the most appropriate solution.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Remove prefork MPM.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jul 11, 2000 at 10:14:58AM -0700, rbb@covalent.net wrote:
> On Tue, 11 Jul 2000, Rodent of Unusual Size wrote:
>
> > rbb@covalent.net wrote:
> > >
> > > I would like to remove the prefork MPM Tuesday. Does anybody have
> > > a problem with that?
> >
> > Yep, I do. We need to keep a true prefork MPM around, not an
> > emulated one that requires threads and thread locking.
>
> There is no reason to have as much duplicated code as the Unix MPMs
> have. I can remove most of the duplicated code, but that requires opening
> up a lot of static variables. The more duplicated code we have, the more
> times we have to fix the same bug.
Rather than jamming them all together, why not simply create more mpm_common
functions? If they need state, then start passing around the data (instead
of global variables). Or a context structure.
> I am in the middle of fixing mpmt so that it doesn't require any of the
> threads stuff. That is an optimization though, and it can wait for a day
> or two.
I fear that mpmt.c is going to become unmaintainable because of all the
#ifdef code in there.
Sharing code through mpm_common seems like the most appropriate solution.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Remove prefork MPM.
Posted by dean gaudet <dg...@arctic.org>.
it's my opinion that the duplicated code is code that needs proper
modularization. it's crap still around from the 1.x http_main.c and
hasn't been cleaned up yet.
... and that an emulated prefork is probably going to be more of a pain in
the ass to debug than a simple prefork.
-dean
On Tue, 11 Jul 2000 rbb@covalent.net wrote:
> On Tue, 11 Jul 2000, Rodent of Unusual Size wrote:
>
> > rbb@covalent.net wrote:
> > >
> > > I would like to remove the prefork MPM Tuesday. Does anybody have
> > > a problem with that?
> >
> > Yep, I do. We need to keep a true prefork MPM around, not an
> > emulated one that requires threads and thread locking.
>
> There is no reason to have as much duplicated code as the Unix MPMs
> have. I can remove most of the duplicated code, but that requires opening
> up a lot of static variables. The more duplicated code we have, the more
> times we have to fix the same bug.
>
> I am in the middle of fixing mpmt so that it doesn't require any of the
> threads stuff. That is an optimization though, and it can wait for a day
> or two.
>
> Ryan
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
Re: Remove prefork MPM.
Posted by rb...@covalent.net.
On Tue, 11 Jul 2000, Rodent of Unusual Size wrote:
> rbb@covalent.net wrote:
> >
> > I would like to remove the prefork MPM Tuesday. Does anybody have
> > a problem with that?
>
> Yep, I do. We need to keep a true prefork MPM around, not an
> emulated one that requires threads and thread locking.
There is no reason to have as much duplicated code as the Unix MPMs
have. I can remove most of the duplicated code, but that requires opening
up a lot of static variables. The more duplicated code we have, the more
times we have to fix the same bug.
I am in the middle of fixing mpmt so that it doesn't require any of the
threads stuff. That is an optimization though, and it can wait for a day
or two.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Remove prefork MPM.
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> I would like to remove the prefork MPM Tuesday. Does anybody have
> a problem with that?
Yep, I do. We need to keep a true prefork MPM around, not an
emulated one that requires threads and thread locking.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>