On Thu, 18 Mar 2004, William A. Rowe, Jr. wrote:

> All of the following seems stale... no?
> 
> >Compile-Time Configuration Issues
> >
> >Atomic Operations
> >
> >The --enable-nonportable-atomics option is relevant for the following platforms: 
> >Solaris on SPARC 
> >By default, APR uses mutex-based atomics on Solaris/SPARC. If you configure with 
> >--enable-nonportable-atomics, however, APR generates code that uses a SPARC v8plus 
> >opcode for fast hardware compare-and-swap. If you configure Apache with this 
> >option, the atomic operations will be more efficient (allowing for lower CPU 
> >utilization and higher concurrency), but the resulting executable will run only on 
> >UltraSPARC chips. 
> 
> We axed this code due to licensing issues --- right?
> 
> >DYNAMIC_MODULE_LIMIT
> >
> >If you have no intention of using dynamically loaded modules (you probably don't if 
> >you're reading this and tuning your server for every last ounce of performance) 
> >then you should add -DDYNAMIC_MODULE_LIMIT=0 when building your server. This will 
> >save RAM that's allocated only for supporting dynamically loaded modules.
> 
> Harmful if swallowed?  We default to a dso-based server now.

A significant amount of the stuff in the performance document was copied
wholesale from the 1.3 docs, and left as is because nobody understood
it. I'll make these suggested changes, but we'd also appreciate further
comments about that doc. It seems that when I read that doc, roughly
halfway down -- basically from the place that says Warning: This 
section has not been fully updated, and down from there - my eyes glaze
over and I'm not sure what actual benefit it is giving to anyone.

-- 
Rich Bowen - [EMAIL PROTECTED]
As we trace our own few circles around the sun
We get it backwards and our seven years go by like one
        Dog Years (Rush - Test for Echo - 1999)

Reply via email to