On my system I just edited the /etc/sysconfig/httpd file to enable the httpd.worker.
After restarting httpd, I ran "ps -ef | grep -i http" and got this:
[root@localhost httpd]# ps -ef | grep -i http
root 16334 17289 0 10:44 pts/1 00:00:00 grep -i http
root 30536 1 0 10:00 ? 00:00:00 /usr/sbin/httpd.worker
apache 30539 30536 0 10:00 ? 00:00:00 /usr/sbin/httpd.worker
apache 30541 30536 0 10:00 ? 00:00:02 /usr/sbin/httpd.worker
[root@localhost httpd]#
If I switch the /etc/sysconfig/httpd back to the default, the ps output is like this:
[root@localhost httpd]# ps -ef | grep -i http
root 16447 1 0 10:47 ? 00:00:00 /usr/sbin/httpd
apache 16448 16447 0 10:47 ? 00:00:00 /usr/sbin/httpd
apache 16449 16447 0 10:47 ? 00:00:00 /usr/sbin/httpd
apache 16450 16447 0 10:47 ? 00:00:00 /usr/sbin/httpd
apache 16451 16447 0 10:47 ? 00:00:00 /usr/sbin/httpd
apache 16453 16447 0 10:47 ? 00:00:00 /usr/sbin/httpd
apache 16454 16447 0 10:47 ? 00:00:00 /usr/sbin/httpd
apache 16455 16447 0 10:47 ? 00:00:00 /usr/sbin/httpd
apache 16456 16447 0 10:47 ? 00:00:00 /usr/sbin/httpd
root 16458 17289 0 10:47 pts/1 00:00:00 grep -i http
[root@localhost httpd]#
And in this case the "httpd -V" output is the same as before.
Since the number of running processes matches my configuration options for the prefork and worker modules set in the "/etc/httpd/conf/httpd.conf" I believe it's working as advertised.
I suspect the "httpd -V" is reporting the compiled in defaults.
because: server binary names are different.
httpd (prefork,default) != httpd.worker (non-default)
Dan
There are a number of MPM modules (Multi-Processing Modules), but by far the most widely used (at least on *nix platforms) are the three main ones: prefork, worker, and event. Essentially, they represent the evolution of the Apache web server, and the different ways that the server has been built to handle HTTP requests within the computing constraints of the time over its long (in software terms) history.
mpm_prefork is.. well.. it's compatible with everything. It spins off a number of child processes for serving requests, and the child processes only serve one request at a time. Because it's got the server process sitting there, ready for action, and not needing to deal with thread marshaling, it's actually faster than the more modern threaded MPMs when you're only dealing with a single request at a time - but concurrent requests suffer, since they're made to wait in line until a server process is free. Additionally, attempting to scale up in the count of prefork child processes, you'll easily suck down some serious RAM.
It's probably not advisable to use prefork unless you need a module that's not thread safe.
Use if: You need modules that break when threads are used, like mod_php. Even then, consider using FastCGI and php-fpm.
Don't use if: Your modules won't break in threading.
mpm_worker uses threading - which is a big help for concurrency. Worker spins off some child processes, which in turn spin off child threads; similar to prefork, some spare threads are kept ready if possible, to service incoming connections. This approach is much kinder on RAM, since the thread count doesn't have a direct bearing on memory use like the server count does in prefork. It also handles concurrency much more easily, since the connections just need to wait for a free thread (which is usually available) instead of a spare server in prefork.
Use if: You're on Apache 2.2, or 2.4 and you're running primarily SSL.
Don't use if: You really can't go wrong, unless you need prefork for compatibility.
However, note that the treads are attached to connections and not requests - which means that a keep-alive connection always keeps a hold of a thread until it's closed (which can be a long time, depending on your configuration). Which is why we have..
mpm_event is very similar to worker, structurally; it's just been moved from 'experimental' to 'stable' status in Apache 2.4. The big difference is that it uses a dedicated thread to deal with the kept-alive connections, and hands requests down to child threads only when a request has actually been made (allowing those threads to free back up immediately after the request is completed). This is great for concurrency of clients that aren't necessarily all active at a time, but make occasional requests, and when the clients might have a long keep-alive timeout.
The exception here is with SSL connections; in that case, it behaves identically to worker (gluing a given connection to a given thread until the connection closes).
Use if: You're on Apache 2.4 and like threads, but you don't like having threads waiting for idle connections. Everyone likes threads!
Don't use if: You're not on Apache 2.4, or you need prefork for compatibility.
In today's world of slowloris, AJAX, and browsers that like to multiplex 6 TCP connections (with keep-alive, of course) to your server, concurrency is an important factor in making your server scale and scale well. Apache's history has tied it down in this regard, and while it's really still not up to par with the likes of nginx or lighttpd in terms of resource usage or scale, it's clear that the development team is working toward building a web server that's still relevant in today's high-request-concurrency world.
Best Answer
The Multi-Processing Modules are part of Apache 2.2, and are included with the apache2 install. You just need to "switch" from whatever MPM you are currently using to the worker MPM. NOTE: You can ONLY start Apache with a single MPM selected, i.e. you MUST "dismod" the current and then "enmod" the desired.
To determine which MPM is currently in use, run
apache2ctl -V. You will see a line such as:Assuming that you are running "prefork" (as in the above example), the switch is made with the following commands:
NOTE: If you are not logged in as root (and you should NOT be!), you will probably need to preface each command line with
sudoto have sufficient privileges.