My very first experience of setting up a live cloud server was one I had looked forward to with optimism.
In the past I was comfortable with the shared hosting and semi dedicate solutions which provided the basic tools for managing a website. But then I needed shell access and hosting my applications using the dedicated solutions provided by the shared hosting companies was costing a lot more than I bargained for.
After getting several warning emails from my shared hosting company at the time for exceeding resource usage, there was just one option left – move.
Almost everyone is used to the localhost setup of a WAMP or LAMP stack. However, these implementations are built to run on a single computer without the rigors that a constantly active webserver experiences.
In the case of a live webserver on the internet you need to tweak and tune stuff in order to ensure your server doesn’t get overrun on this highway. Crawlers, Spiders, and SPAM bots all contribute to traffic on your server and you need to plan to manage them.
Setting up your LAMP stack is somewhat straight forward (on Debian, Ubuntu type: sudo apt-get install apache2 php5 libapache2-mod-php5).
I wouldn’t go into the details of setting that up here. What I want to share on the other hand is the effect of going along with the default implementation of the LAMP stack, and particularly the implementation of the Apache server that it comes bundled with.
By default, most new installations of Apache install the prefork memory management module (mpm-prefork) which handles each connection using a single process.
Sort of like having multiple instances of Apache running at the same time on the server. However, after several cases of server thrashing (endless memory swapping), I was left with two choices (other than increasing the RAM again). Either switch to Nginx which by default is built to work with PHP as a Fast CGI script, or configure Apache to run PHP using FastCGI with mpm-worker.
Due to time constraints I had to make the switch quick and I was sure I didn’t have enough time to debug a faulty new Nginx install. So I opted to go with the least intensive and more familiar option of changing Apache’s MPM to from prefork to worker.
Highlighted below are the simple steps I took to make this work in less than thirty minutes.
Note that the commands are for Debian distributions of Linux.
- Install the FPM CGI binary for PHP. apt-get install php5-fpm
- This will run as a daemon and you need to configure to run as a socket instead of it listening on a local port.
- Open the file located at /etc/php5/fpm/pool.d/www.conf
- Comment the line with listen = 127.0.0.1:9000 by adding a semicolon to the beginning of that line so it becomes ;listen = 127.0.0.1:9000
- Now add a line after it with the following: listen = /var/run/php5-fpm.sock
which makes PHP-FPM run as a socket
- Restart the service by entering: service php5-fpm restart
- Now you need to install the FastCGI module for Apache’s worker MPM which would replace prefork. So you enter apt-get install libapache2-mod-fastcgi
- Once the installation is complete, Apache would have replaced your default prefork MPM with the new FastCGI module for worker.
- Finally you need to configure your sites to use the new FASTCGI module. It is preferable to make the changes to your main Apache configuration file located at /etc/apache2/apache2.conf
- Use this config below making sure the directory path below exists or create a path that can be accessed on the server file system
- <IfModule mod_fastcgi.c>
AddHandler php5-fcgi .php
Action php5-fcgi /php5-fcgi
Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi
FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi -socket /var/run/php5-fpm.sock -pass-header Authorization
- If you are using virtual hosts it is still preferable to make the changes in the main Apache config file in /etc/apache2/apache2.conf instead of adding it to each config file for each site you have enabled.
- Now, all that is left is for you to restart your web server typing the command: service apache2 restart
And that’s all to it. Your server should now work faster and suffer fewer memory outages than when it was configured to use prefork.
Best of luck in your adventure towards better performance …