Bug 127607 - Bad combination of threaded MPM and mod_cgi results in performance loss
Bad combination of threaded MPM and mod_cgi results in performance loss
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: httpd (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
http://stingr.net/rpm/ThreadedHTTPDMa...
: FutureFeature
Depends On:
Blocks: FC4Target
  Show dependency treegraph
 
Reported: 2004-07-10 15:57 EDT by Paul P Komkoff Jr
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-27 10:38:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul P Komkoff Jr 2004-07-10 15:57:49 EDT
Description of problem:
httpd (apache 2.0) came with Fedora Core 2 does not scale well. It 
includes worker MPM binary, but it doesn't include mod_cgid (which is 
better in threaded environment)

This actually limits performance of httpd.worker. Also, many people 
think that preferred way of running apache is threaded server, so 
we'd better make httpd.worker the default httpd.

The reason why mod_cgid cannot be included in standard distribution 
is extremely old APR (Apache Portable Runtime) used to build and run 
httpd. This comes up from right distribution policy (if many packages 
use APR let it be shared and disable bundled APRs) but lame APR 
release cycle. Latest available as separate release apr 0.9.4 lacks a 
couple of functions used in mod_cgid.

I fixed this in least expensive way.
I've prepared 2 rpms (apr and apr-util), to which I've added latest 
snapshots of corresponding packages taken from their distribution 
site (e.g. apr.apache.org). Now anyone can safely build mod_cgid.

Another problem I've faced is multi-user virtual hosting.

There are 2 possible solutions to this: run multiple apache instances 
on different combinations of localhost:(port) with one acting as a 
front end (mod_proxy), and use proper apache infrastructure.
There was an attempt to create such infrastructure. perchild mpm. Now 
it is dead. But before death it forked into which now known as 
metuxmpm.
And now metuxmpm is available as httpd.metuxmpm binary which is in 
httpd rpm I've provided.

Also, because base build dir is now threaded (worker), I think all 
apxs-using stuff like php will recognize things correctly and enable 
thread safety in their own builds.

The described packages are available at:
http://gw6.sgu.ru/yum/fedora/contrib/SRPMS - source rpms apr, apr-
util, httpd 
http://gw6.sgu.ru/yum/fedora/contrib/i386 - binaries for i386


Version-Release number of selected component (if applicable):
httpd-2.0.50-3
Comment 1 Joe Orton 2004-07-14 04:22:53 EDT
It's better to file separate bugs on separate issues.

1) worker will not be the default MPM for a long time.

2) exactly what is the APR issue which prevents mod_cgid being built?

3) have you benchmarked mod_cgi vs mod_cgid?  If you could post the
results of such benchmarking to fedora-devel-list we can discuss
including mod_cgid again.
Comment 2 Paul P Komkoff Jr 2004-07-14 07:29:43 EDT
Sorry, I thought they all will go to you ... :)

1) Well maybe it worth hack php.spec to build it threadsafe to allow 
wider usage and testing of nondefault httpd.worker ?

2) mod_cgid won't build because apr-0.9.4 lacks apr_os_pipe_put_ex.

3) I will try to make adequate and reproducible benchmark.
Comment 3 Joe Orton 2004-11-11 10:06:40 EST
Needs investigation for FC4.
Comment 4 Joe Orton 2005-04-27 10:38:38 EDT
mod_cgid.so is built again but I'm not going to enable it by default unless
there are some convincing reasons

I did some basic benchmarking with ab of a printenv CGI script: mod_cgid was at
most 10% higher for some concurrency levels; trailing out to approximately
equivalent performance at higher concurrency, but maybe that was just because I
was hitting the scaling limit of the system.

Note You need to log in before you can comment on or make changes to this bug.