I have few questions on the file layout. As far as I understand, for this kind
of layout, we will have a single apr library libapr-1.so and that will be 
multithreaded support. So in apr headers (apr.h) HAS_APR_THREADS will be set to
1.

Apache modules uses HAS_APR_THREADS macro to know if apr has threads or not.
In apache modules, developer uses various locks to avoid race conditions.

What my concern is that if some developer want to compile his apache module
for prefork mpm, his module will be compiled with HAS_APR_THREADS=1 and
customer's module will unnecessarily uses locks to avoid contention. This might
affect the performance of prefork apache (i.e on Niagra platforms).

Infact in the suggested layout, all of the apache module will use threaded
version of apr libraries even for prefork mpm (search for APR_HAS_THREADS in
httpd-2.2.x/modules directory).  I think we need to find out if it affects
performance badly before having a closure on file layout. I think that it will
affect adversely much on niagra architecure where we have 32/64 cpus.

Regards,
Basant.

Note: Redhat/Fedora follows the above approach to have single apr library which
have threads enabled.



On Wed, Aug 22, 2007 at 02:10:49PM +0530, Seema Alevoor wrote:
> 
> Jyri Virkki wrote:
> > I went through all the Apache threads so far this afternoon to
> > summarize the current state of discussion, here is where I believe
> > things stand:
> > 
> > - The next case will support both worker and prefork MPM. I believe
> >   we have closure on this. Seema has posted details on the delivery.
> > 
> > - Configuration of MPM choice. Seema, can you summarize the answer?
> 
> Our Apache installation will have both prefork and wokrer mpm binaries. The 
> default
> server "httpd" will use prefork mpm model. The one that uses worker mpm model 
> will be
> named as httpd.worker. To choose between these servers, we can use one of the 
> following
> 
> 1. set HTTPD variable within /usr/apache2/bin/envvars.
>       envvars is already sourced within apachectl. This is applicable when 
> invoked
> as SMF service as Apache smf service internally invokes apachectl.
> 
> 2. use a smf property for the svc:/network/http:apache2 service.
>       This works when Apache is started as a SMF service.
> 
> 3. use a different (new) file "/etc/default/httpd" to define HTTPD variable 
> and modify apachectl
> to source this file.
>       /etc/default is a deprecated method of storing configuration
> information. Hence not recommended.
> 
> 
> > - Closure on file layout versioning. The 2007/169 case had
> >   /usr/apache2 (and corresponding places in /etc and /var). There's
> >   been much discussion on whether to stay the course or permit minor
> >   releases of 2.x to coexist (and there are several way to accomplish
> >   that, but the higher order question is whether coexistence is the goal).
> >   The main argument for this appears to be for upgrades, so that upgrading
> >   from S10 doesn't break a working installation.
> 
> > - There was discussion of adding a 'build' directory. Closure?
> 
> Correction...we are not adding "build" directory. We are moving "build" 
> directory
> currently under /var/apache2 to /usr/apache2 directory.
> Reason: apxs expects the build directory to be under "%PREFIX%" which is, in 
> our case,
> "/usr/apache2" dir.
> 
> There was also a discussion on including *.conf within httpd.conf-example 
> file.
> I think we have a closure on this. We will be retaining the existing 
> commented lines
> to include individual .conf files as well as adding a commented line to 
> include
> /etc/apache2/extra/*.conf files.
> 
> > - There were various proposals on directory name changes (modules,
> >   conf.d) but the consensus was that names should not change unless
> >   there is a strong reason. So I believe there is closure on existing
> >   names (libexec, extras).
> > 
> > Thoughts? Corrections? Etc? Hit list reply...
> > 
> > 
> 
> Thanks and Regards,
> Seema.
> _______________________________________________
> webstack-discuss mailing list
> webstack-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss

Reply via email to