View compiled modules in Apache
/usr/sbin/httpd –l
'Multi Processing Modules' or generally MPMs are the modules that get the primary attention in Apache. Apache has been known for its extensibility through modules and this is one of the main reason that it has been favoured worldwide, apart from its rock stabilty.
MPMs are supposed to do the rigorous work of binding to the port specified, accepts the connection requests, generate the child processes according to the load of the server and dispatch the children for the incoming connections. They are loaded along with 'httpd' at startup time. Many an MPM exists, but one and only one can exist in a running Apache installation. The default MPM for Unix is the 'Prefork' module. The default MPMs which exist for other platforms are :
BeOS : beos
Netware : mpm_netware
OS/2 : mpmt_os2
Windows : mpm_winnt
he main difference between MPMs and normal modules is that only one of the former can be used and multiple ones can be loaded in the latter. MPMs must be chosen during install and can be compiled into the binary using the '--with-mpm=NAME' option. If any of the MPMs are not specified, then the default MPM, 'prefork', will be compiled. Apache in Windows is now more efficient since it does not need to use the POSIX compliance and can use the native networking features of the OS. In the Windows environment,the MPM 'mpm_winnt' is used as the default.
Two of the MPMs specified in 'httpd.conf' are 'prefork' and 'worker'. These two MPMs exists for different specifications. The 'worker' MPM was introduced in Apache2. It uses a multiprocess-multithreaded structure and starts a thread for each of the connection, ie.. the number of child servers starts the threads according to the directives 'ThreadsPerChild', 'MinSpareThreads' and 'MaxSpareThreads'. By using a threaded structure, each child server can handle more than one connection, upto the limit specified by 'MaxSpareThreads'. The parent process is responsible for starting the child processes. The child instances in turn start the number of threads specified by 'ThreadsPerChild' and one additional thread for listening to incoming requests. The main drawback is that it makes more demands on your RAM and since one child server handles more than one thread (each thread equals one connection), anything that effects a particular child process has the same effect on the connections. In short, one crashed child process means more than one lost connection. But in the case of 'prefork' module, the concept of threads doesn't exist. A seperate child process get started for each incoming connection, provided within the limit specified. This concept is more geared towards stability since each child process has to handle only its own connection.
####################################################################
The Apache HTTP Server is designed to be a powerful and flexible web server that can work on a very wide variety of platforms in a range of different environments. Different platforms and different environments often require different features, or may have different ways of implementing the same feature most efficiently. Apache has always accommodated a wide variety of environments through its modular design. This design allows the webmaster to choose which features will be included in the server by selecting which modules to load either at compile-time or at run-time.
Apache 2.0 extends this modular design to the most basic functions of a web server. The server ships with a selection of Multi-Processing Modules (MPMs) which are responsible for binding to network ports on the machine, accepting requests, and dispatching children to handle the requests.
Extending the modular design to this level of the server allows two important benefits:
Apache can more cleanly and efficiently support a wide variety of operating systems. In particular, the Windows version of Apache is now much more efficient, since mpm_winnt can use native networking features in place of the POSIX layer used in Apache 1.3. This benefit also extends to other operating systems that implement specialized MPMs.
The server can be better customized for the needs of the particular site. For example, sites that need a great deal of scalability can choose to use a threaded MPM like worker, while sites requiring stability or compatibility with older software can use a prefork. In addition, special features like serving different hosts under different userids (perchild) can be provided.
This Multi-Processing Module (MPM) implements a hybrid multi-process multi-threaded server. By using threads to serve requests, it is able to serve a large number of requests with less system resources than a process-based server. Yet it retains much of the stability of a process-based server by keeping multiple processes available, each with many threads.
The most important directives used to control this MPM are ThreadsPerChild, which controls the number of threads deployed by each child process and MaxClients, which controls the maximum total number of threads that may be launched.
A single control process (the parent) is responsible for launching child processes. Each child process creates a fixed number of server threads as specified in the ThreadsPerChild directive, as well as a listener thread which listens for connections and passes them to a server thread for processing when they arrive.
Apache always tries to maintain a pool of spare or idle server threads, which stand ready to serve incoming requests. In this way, clients do not need to wait for a new threads or processes to be created before their requests can be served. The number of processes that will initially launched is set by the StartServers directive. Then during operation, Apache assesses the total number of idle threads in all processes, and forks or kills processes to keep this number within the boundaries specified by MinSpareThreads and MaxSpareThreads. Since this process is very self-regulating, it is rarely necessary to modify these directives from their default values. The maximum number of clients that may be served simultaneously (i.e., the maximum total number of threads in all processes) is determined by the MaxClients directive. The maximum number of active child processes is determined by the MaxClients directive divided by the ThreadsPerChild directive.
Two directives set hard limits on the number of active child processes and the number of server threads in a child process, and can only be changed by fully stopping the server and then starting it again. ServerLimit is a hard limit on the number of active child processes, and must be greater than or equal to the MaxClients directive divided by the ThreadsPerChild directive. ThreadLimit is a hard limit of the number of server threads, and must be greater than or equal to the ThreadsPerChild directive. If non-default values are specified for these directives, they should appear before other worker directives.
This Multi-Processing Module (MPM) implements a non-threaded, pre-forking web server that handles requests in a manner similar to Apache 1.3. It is appropriate for sites that need to avoid threading for compatibility with non-thread-safe libraries. It is also the best MPM for isolating each request, so that a problem with a single request will not affect any other.
This MPM is very self-regulating, so it is rarely necessary to adjust its configuration directives. Most important is that MaxClients be big enough to handle as many simultaneous requests as you expect to receive, but small enough to assure that there is enough physical RAM for all processes.
A single control process is responsible for launching child processes which listen for connections and serve them when they arrive. Apache always tries to maintain several spare or idle server processes, which stand ready to serve incoming requests. In this way, clients do not need to wait for a new child processes to be forked before their requests can be served.
The StartServers, MinSpareServers, MaxSpareServers, and MaxClients regulate how the parent process creates children to serve requests. In general, Apache is very self-regulating, so most sites do not need to adjust these directives from their default values. Sites which need to serve more than 256 simultaneous requests may need to increase MaxClients, while sites with limited memory may need to decrease MaxClients to keep the server from thrashing (swapping memory to disk and back). More information about tuning process creation is provided in the performance hints documentation.
While the parent process is usually started as root under Unix in order to bind to port 80, the child processes are launched by Apache as a less-privileged user. The User and Group directives are used to set the privileges of the Apache child processes. The child processes must be able to read all the content that will be served, but should have as few privileges beyond that as possible.
MaxRequestsPerChild controls how frequently the server recycles processes by killing old ones and launching new ones.
In computer science, a thread of execution is the smallest unit of processing that can be scheduled by an operating system. It generally results from a fork of a computer program into two or more concurrently running tasks. The implementation of threads and processes differs from one operating system to another, but in most cases, a thread is contained inside a process. Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources. In particular, the threads of a process share the latter's instructions (its code) and its context (the values the various variables have at any given moment). To give an analogy, multiple threads in a process are like multiple cooks reading off the same cook book and following its instructions, not necessarily from the same page.
On a single processor, multithreading generally occurs by time-division multiplexing (as in multitasking): the processor switches between different threads. This context switching generally happens frequently enough that the user perceives the threads or tasks as running at the same time. On a multiprocessor or multi-core system, the threads or tasks will actually run at the same time, with each processor or core running a particular thread or task.
Threads differ from traditional multitasking operating system processes in that:
processes are typically independent, while threads exist as subsets of a process
processes carry considerable state information, whereas multiple threads within a process share state as well as memory and other resources
processes have separate address spaces, whereas threads share their address space
processes interact only through system-provided inter-process communication mechanisms.
Context switching between threads in the same process is typically faster than context switching between processes.