httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton" <>
Subject Re: Inclusion of mpm-itk into HEAD
Date Mon, 25 Jun 2007 04:36:41 GMT
A few comments below, but a few questions first to satisfy my own curiosity.

What specific applications are you running that require things to be
run as a distinct user? Are these applications implemented directly in
C as custom Apache modules, or are you writing stuff in other
languages, ie., such as PHP, Perl, running under mod_php or mod_perl?
What are the perceived reasons that solutions such as mod_fastcgi,
mod_scgi or the various mod_proxy type solutions wouldn't be a viable
alternative for hosting your application?

On 18/06/07, Steinar H. Gunderson <> wrote:
> [Please Cc me on any replies, I'm not subscribed to the list]
> Hi,
> I'd like to request the inclusion of the ITK MPM (mpm-itk) as an official MPM
> in the Apache tree, for Apache 2.4/3.0. mpm-itk is basically a modified
> prefork allowing each vhost to run as a different uid/gid, ie. sort of like
> what perchild was supposed to do. The biggest differences between mpm-itk and
> perchild/Metux/peruser are:
>  - mpm-itk is in production use at several sites -- for instance, most sites
>    under generally use mpm-itk, totaling about nine million hits a
>    day. Even though it is still under experimental/ in the tree, most real
>    issues have long since been ironed out -- it is not a proof-of-concept,
>    but a real, working tool. It works flawlessly with SSL and most
>    third-party modules (mod_ruby being a notable exception).
>  - mpm-itk is not threaded, which means you can run the full range of evil
>    third-party modules (such as PHP and its extensions) without problems.

Known not to work with current versions of mod_python. This is because
mod_python uses process mutexes for session locking between processes
and the changing uid of the processes causes problems with this.
Possible solutions have been discussed in:

>  - mpm-itk does not require any sort of special kernel modules or
>    configuration. It should generally work on the same platforms as prefork
>    does, given that it's a direct prefork descendent. It's a pluggable
>    replacement for prefork; most sites wouldn't really notice the difference
>    if you took out prefork and replaced it with mpm-itk, until you start
>    actually using AssignUserID. This provides a smooth migration path.
> Two main disadvantages should be noted:
>  - setuid() happens after the request has been parsed, which means that the
>    server runs as root up until that point. (However, on a system with
>    capabilities, ie. Linux 2.6, almost all superuser privileges are dropped,
>    so you can't just load kernel code or whatever.)
>  - There is a performance drop from prefork, as each child is only serving
>    one connection before it dies -- I haven't done any detailed benchmarking
>    on this, but my general impression is: If you're serving static content
>    and you're strained for performance, it matters. If you're serving dynamic
>    content or large static files, it probably just disappears in the equation.

For mod_python based Python applications such as Django and
TurboGears, which have a memory footprint starting at about 7MB and
15MB respectively, any performance loss would not 'just disappear in
the equation" as the load time for each request would be significant
given that process would be thrown away after each request and
everything would need to be reloaded.

So for mod_python at least, this MPM would be totally impractical
anyway for anything but small applications even if the locking issue
were resolved.


> Despite these disadvantages, I believe it would be a useful addition to the
> upstream tree -- these are largely results of design decisions in order to
> keep the design as close to prefork as possible, instead of designing a new
> grand scheme that will take a lot of time to get right. mpm-itk is included
> in at least Debian, Ubuntu, Gentoo, and in FreeBSD ports, and based on the
> numbers from Debian's popularity contest (which is not a statistically valid
> sample, but nevertheless a good indication) is the third most popular MPM
> (after prefork and worker, but clearly ahead of event).
> The full set of patches, against Apache 2.2.3, is available from
> I'll of course be happy to update these to apply against HEAD if needed,
> transfer copyright to the ASF, and write any needed documentation. However,
> given that the "runs as root" issue has proved somewhat controversial
> earlier, I don't think it's appropriate to do that kind of upstream
> integration work before some kind of decision has been made :-)
> /* Steinar */
> --
> Homepage:

View raw message