A note to the reader
This post is a legacy post. The legacy posts that are available on this website were written many years ago. These posts are made available here for archival purposes only.
They reflect the age I was, and the level of knowledge that I had when I wrote them, and they may contain outdated information, so please keep that in mind as you proceed to read this article.
Original Title: How to install a highly optimized LAMP stack with mpm_event and MariaDB
Apache is today more important as a web server than ever before. Most PHP scripts assume (or even require) apache to be installed in order to run. However, for most people running a VPS with less than a GB of RAM, having to run apache is a deal breaker. The same applies for the stock MySQL configuration. This tutorial will help you to install Apache with the event MPM + PHP [fastcgi] + MariaDB 5.5
Step 1 - Install Prerequisites
This tutorial requires root. If you’re not already root, run this command:
|
|
and gain root priviledges. Alternatively, you may prefix the commands with sudo
also.
We will use the aptitude package manager as a replacement for apt-get. Since it is not available by default, go ahead and install it.
|
|
Step 2 - Install Apache
Apache is sometimes included by default by ubuntu, however aptitude will take care of removing the preform mpm when we install the apache fastcgi module, and the event mpm
|
|
Then, we disable the build in apache php modules as they consume too much precious memory
|
|
Then, we will enable the mod_fastcgi, mod_ssl, mod_actions and mod_rewrite
|
|
Step 3 - Install PHP
We will be running PHP as a FastCGI process. We will configure FastCGI to run as a separate server and have a 120 second timeout.
First, we configure the apache2 fastcgi module.
|
|
|
|
Finish off by creating the FPM directory
|
|
Then, we install the php packages Base PHP packages. Essential to run PHP
|
|
Secondary, but useful PHP modules/packages. Feel free to omit
|
|
And, we’re done installing PHP
Step 4 - Install MariaDB
We will be using MariaDB as our database server. It is an enhanced, drop-in replacement for MySQL that is developed by the original team and is more performant
Install MariaDB
|
|
Secure MariaDB
|
|
And we’re done!
Step 5 - Pre-Optimization
Before we optimize, we need to restart apache2 and php.
|
|
Step 6 - Optimize Apache
The only optimization apache really needs is the config optimization. Edit the config file:
|
|
|
|
Step 7 - Optimize FPM
Note: Most of these steps are done with automated linux tools like
sed
which make it easy to edit the configuration files. If you want to know what’s going on behind the scenes, refer to the comments above each command block.
Before we optimize FPM, we need to stop the service
|
|
The FPM configuration file is lengthy and complex. To quickly do the configuration automatically, run:
|
|
pm.max_children
is the configuration value that controls the maximum number of server processes that will be
started by FastCGI. 5 is usually enough, but it might be a good idea to set it to 10 or 15 for a high traffic site
on a high-end vps
|
|
pm.start_servers
is the number of servers to be initially started by FastCGI. 1 is nearly always enough. Try 2 or 3 for higher traffic sites. Make sure that is it less that pm.max_children
.
|
|
pm.min_spare_servers
is the minimum number of server processes FastCGI will have ready to handle additional load. Each server process is respawned when it hits pm.max_requests
. It is here that this value becomes useful. It ensures that the site will not go offline for even a small amount of time, and will remain performant even under load. 1 is enough for small sites (< 5000 views / minute). For larger sites, try 5 or 6.
|
|
pm.max_spare_servers
exists for only one reason: to prevent FastCGI from consuming too many resources in the event of high load. This is the
number of maximum server processes that will be kept ready by FastCGI. Make sure it is at least half of pm.max_children
and greater than
pm.min_spare_server
s. 2 is OK for a small site. Try 9 or 10 for a large site
|
|
pm.max_requests
controls the maximum number of hits a FastCGI process is allowed to serve before it is killed and respawned. This value
is there in place to deal with the fact that over time, these processes leak memory. Periodically killing and respawning them allows
us to keep the site snappy. 5000 is a pretty good value to begin with, give or take a couple hundreds. If pm.min_spare_server
s is < 5, and
this value is < 5000, the site will become more sluggish. Never set it to a 3 digit or less number. Always ensure that it is >= 5000
|
|
Change to socket connection for better performance
|
|
Now, configure the php.ini file.
|
|
max_execution_time
is the maximum amount of time (in seconds) that a script is allowed to execute for, before it is killed. 120 is a big enough number to do most heavy calculations, but this number may be increased if many computations are required to be performed or heavy downloading needs to be done.
|
|
memory_limit
is the maximum amount of memory (in MB) that a PHP script is allowed to take up. 192 is more than
enough for most jobs, but you may consider raising it if you want to do heavy computations.
|
|
This is the maximum amount of time (in seconds) for which a client can upload data to the server through a keep-alive connection. 300 seconds (or 5 minutes) is usually enough. You may want to set it to something like 6300 (2 hours) if you plan on uploading huge files.
|
|
post_max_size
is the maximum size (in MB) of the data that can be sent to the server through a POST request. 50 MB is usually more than enough for most needs, but feel free to change to will.
|
|
upload_max_filesize
is the maximum size of an individual file (in MB) that can be uploaded. Change at will.
|
|
Don’t expose PHP. More of a security fix than memory optimization
|
|
Disable potentially dangerous PHP functions that may allow attackers to execute arbitary code on your machine.
|
|
Now we restart all the services
|
|
Step 8 - Optimize MariaDB
MariaDB configuration is quite easy to optimize. Just dropping InnoDB can cause a huge performance gain.
|
|
|
|
Now we restart the service
|
|
Step 9 - Reboot
Reboot the server to get better performance
|
|
Step 11 - Set up a non-root sudo-enabled user
We will use this user’s home directory to contain our vhosts. Add the User
|
|
Grant him priviledges
|
|
Step 12 - Add a virtualhost
Replace “example.com” with your domain Replace “demo” with your user Create an FPM user
|
|
Restart FPM
|
|
Create a public_html for your domain
|
|
Create the log files:
|
|
Set permissions
|
|
Create the VirtualHost file
|
|
|
|
Enable the virtualhost
|
|
Test the virtualhost
|
|
|
|
navigate to your domain in the browser and see that it’s working correctly.
Conclusion
Now that you know how to install and optimize a LAMP stack, get cracking and create a great site that will be big enough to crash this setup!
Read Next
I’m running an experiment for better content recommendations. These are the 3 posts that are most likely to be interesting for you:
-
Install Postgres into XAMPP on Windows
After mastering LAMP stack optimizations for Linux, you might be intrigued by the versatility of integrating Postgres with XAMPP on Windows, expanding your development environment capabilities. -
3 ways to render inline lists in PHP
After mastering the art of optimizing your LAMP stack for peak performance, you’ll appreciate the finesse of using PHP to seamlessly render inline lists, a skill that complements your server optimization efforts by enhancing your web applications’ efficiency and user experience. -
Accidentally deleted your .bashrc?
After mastering the art of optimizing your LAMP stack, learning how to recover and customize your bash environment can be your next step to becoming a Linux server wizard.