Adam Prime wrote: > André Warnier wrote: >> Maybe this is the time to ask. >> I am using Linux Debian, and getting Apache 2, perl and mod_perl 2 >> from there (apt-get). >> I have never been quite sure which mpm the packager decided to >> configure, as the apache2.conf contains parameters for prefork, >> pthread and perchild. So, >> a) which is the best way to find out ? >> b) if it happened to be "worker" or something, could I just change >> that to "prefork", or is there more to it ? >> >> (Also so far, even if it is using a threaded mpm, it does not seem to >> have any deleterious effect on my systems, which are pretty stable). >> >> Thanks > ./httpd -V > Server version: Apache/2.0.54 > Server built: Sep 25 2005 00:31:31 > Server's Module Magic Number: 20020903:9 > Architecture: 32-bit > Server compiled with.... > -D APACHE_MPM_DIR="server/mpm/prefork" > ... > > The -D APACHE_MPM_DIR tells you which MPM your apache is using. In > order to change MPM's you need to recompile apache, and quite possibly > mod_perl as well, i have no idea how you'd accomplish that on debian > using apt.
Not probably... you need perl built for threading, and httpd built for threading. There is a very strong probability that httpd 2.4/3.0 will encourage no "prefork" style servers, and by the following major rev, they will be discarded altogether. Already apr builds to support threads unless you are very persistent in telling it "no, thank you". We will never attain async servers/more-requests-than-children until we wholly embrace threading, and free-threading at that :) But your poll doesn't surprise me, Covalent's shipped a threaded perl, both MPM's for now some 6+ years, and the customers have appreciated it significantly. The fact that the PHP project can't persuade people to upgrade 10 year old non-reentrant libraries doesn't change the fact that several linux vendors now ship a worker model by default. I'd hope the modperl crew doesn't follow their nonsensical flip mid-minor-version to make the zts support "experimental/maintainer" - that was lame :) It's better to plow through these issues, and then decide based on real pragmatism and cpu load if prefork or worker is better suited, and then prepare to embrace the next decade of free threaded applications.
