Sander (Temme) and I have been working on this in the last two weeks; basically it turns out that your best mutex stategy is not just a function of the OS, but also of the (type of) load, the # of processors and the speed of those processor's. In particuly - if your bottle neck is a high mutex rate - you are better off using less processor's with a higher speed - or you should change strategy.
Hence the patch which we've been testing on 1,2,4 and 8 processor (sun) machines. But do not expect that work to conclude soonish :-) Dw > Could be cool. But a quick question, what do you expect to gain with > this? Is it for experimentation, or do you believe that having multiple > mutex types will be useful in the same production server? Would this mean > that the Apache code would need to try multiple kinds of locks before it > necessarily found one that worked? > > I guess my only thought is that APR chooses the "best" lock for the > platform based on the groups experience, and what is available. Would > this change then put the onus of defining which lock type is used back on > the programmer? > > Ryan > > _______________________________________________________________________________ > Ryan Bloom [EMAIL PROTECTED] > 406 29th St. > San Francisco, CA 94131 > ------------------------------------------------------------------------------- > > > >
