PHP Apache configurations

Published On: 26 January 2012.By .
  • Digital Engineering
Server Request Response Flow- 
Apache is web server, Its job is to receive the request and send the response. So if I opens a web page mydomain.com/test.html . request goes to server, server checks the mime type(.html in case) , executes the corresponding file and sends the response.
If I open a web page mydomain.com/test.php then also same flow happens. Request goes to server, server checks the mime type(.php), executes the test.php and send the response. But wait a sec, my server doest know how to execute this .php file? Here comes mod_php OR fastCGI. You might have heard about both of them.
Mod_Php – php sits inside the web server and gets loaded just like other modules of apache.
FastCGI– It is not part of web server. It is like a separate application which gets invoked by web server when it receives php mime type requests. Instead of creating a new process for each request, FastCGI uses persistent processes to handle a series of requests. These processes are owned by the FastCGI server, not the web server. FastCgi is a faster version of CGI. It is implemented by mod_fcgid and mod_fastcgi.
setup would be –
Apache MPM+ mod_fcgid
Apache MPM+ mod_fastcgi

mod_fastcgi manage processes (not web server processes) through FastCGI Process Manager, fcgi-pm. This process manager is spawned by Apache at server initialization.

CGI Application Flow – CGI is a gateway to handle executable files (known as CGI scripts)
1. Apache got request GET /your_script
2. Your CGI app is loaded, in case of say Perl it’s compiled first then  loaded. To compile/translate it, the perl would have to be started. When it starts it loads dynamic libraries, which when loaded are pulling  other dynamic libraries (in most cases).
3. When all is settled with Perl, your script is translated.
4. Now we’re ready to execute our script.
5. Your script pulls the data out of environment, does it’s job and calls exit.
6. The memory used by perl is freed, your compiled code is wasted.  the libraries are unloaded and now we’re waiting for step 1, just  to make another similar job.

Quite clear that every time CGI app is loaded, lot of depending libraries are loaded to serve one request and on completion of request CGI app is unloaded. Process repeats for any next request. Repeating loading and unloading is time consuming.

FAST CGI Flow - 
1. Apache got request GET /your_script
2. Your CGI app is loaded, in case of say Perl it’s compiled first then  loaded. To compile/translate it, the perl would have to be started.  When it starts it loads dynamic libraries, which when loaded, are pulling  other dynamic libraries (in most cases).
3. When all is settled with Perl, your script is translated.
4. Now we’re ready to execute our script.
5. Your script pulls the data out of environment, does  it’s job and it goes Back to step 4.

Difference Mod_php AND FAST CGI - 
Conceptually it is quite clear that Mod_php is faster as it is bundled with apache and preloaded so web server is able to serve the request in less time. But this comes with High memory usage as these libraries are always pre loaded even when apache is serving static html files. If you dont have memory problem (you do have it on a shared server) then Mod_php is good to go. But as Mod_php is part of apache php config settings changes wont be reflected without restarting apache (unless you do a dynamic mod_php installation).

PHP-FPM (FastCGI Process Manager) – is an alternative PHP FastCGI implementation with some additional features useful for sites of any size, especially busier sites.
Apache worker + mod_fastcgi + php-fpm
when we use mod_fcid or mod_fastcgi each process has its’s own OPCode cache but  in PHP-FPM that opcode cache is shared across processes. Php-fpm supports socket connection (for local server when web server and cgi server are on same machine) as well as TCP/IP connection (for remote servers). socket connection is definitely faster.
know more at http://php-fpm.org/about/

APACHE MPM Worker and APACHE MPM PREFORK-
Ever wonder how apache handles requests. It has to start a process to serve a request. To manage simultaneous requests it keeps a pool of processes running and keeps forking/killing them to maintain maximum process limit.  lets understand this in detail-

APACHE MPM Worker – It implements a hybrid multi process multi threaded server. It uses threads to serve requests and able to serve more requests with less resource as compared to process based server (Prefork).
– based on apache 2.0
- lower memory consumption and higher performance

How Worker MPM works-

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.

MPM Prefork – It is a non thread server and appropriate for sites that need to avoid threading for compatibility with non-thread-safe libraries.(You might have come across options to download thread-safe/non thread-safe versions of libraries several times.) It isolates each request and handles in  separate process so that a problem with a single request will not affect any other.
– based on apache 1.3
-  stable and secure
– high memory consumption and low performance

How Prefork works
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.


Magento PerformanceTuning

Magento is highly resource extensive. The web server settings play a big role in fine tuning, reducing the load time for website and increasing the number of requests handled.
Mod_php OR FastCGI – well simple answer – if you dont have memory and resource problems then go for mod_php, it is no doubt faster but eats up lot of resources.
Worker OR Prefork – we are using php so we might have to deal with non thread safe third party libraries. PHP5 is thread-safe, but PHP extensions aren’t all thread-safe. And Magento is a PHP application like any other, chances are that you are using some PHP extensions somewhere. So it’s considered harmfull to run a PHP application on a worker-mpm. so using Prefork is a better option.

+ Nishant

Related content

That’s all for this blog