WordPress Projects: Optimization Tips
- Tutorial
Today, Wordpress is one of the most popular CMS. Conceived initially as an engine for blogs, today it is used for a variety of types of sites, in particular, for news portals and online media. Wordpress has corporate websites, educational and entertainment portals.
Wordpress is used by many of our clients, who quite often turn to us with questions about setting up this CMS.
There are many detailed instructions for installing and configuring Wordpress on the Internet. In this article, we would like to touch upon issues that most Wordpress publications do not pay enough attention to. We will talk about how to optimize the work of sites on Wordpress, as well as give some recommendations for improving the level of security and stability. All examples use Ubuntu 12.04.
We configure a DBMS
DBMS selection
As you know, for the operation of Wordpress you need a MySQL database system. Recently, alternative implementations (forks) of this DBMS have become widespread, the most popular of which are Percona Server and MariaDB. Many online installation instructions recommend using MariaDB.
We recommend using Percona Server, as this fork is more productive and stable compared to standard MySQL. In addition, Percona has more features for collecting system statistics.
To install Percona on the server, you must first import the keys:
$ apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
Then you need to add the following repositories to the /etc/apt/sources.list file:
deb http://repo.percona.com/apt precise main deb-src http://repo.percona.com/apt precise main
And execute the command:
$ sudo apt-get update
After that, you can install percona-server using the standard package manager:
$ sudo apt-get install percona-server-server percona-server-client
Choose an engine: MyISAM or InnoDB?
The most popular engines in MySQL databases are MyISAM and InnoDB. If the engine is selected incorrectly, then there are problems with performance and consistency.
Consider the features of these engines in more detail.
MyISAM shows good results on SELECT samples, which is largely due to the lack of transaction support and foreign keys. However, when modifying and adding records, the entire table is temporarily locked, which can cause serious delays during heavy load.
The undoubted advantages of this engine are also full-text search and compression. The data format in MyISAM is cross-platform, which allows you to easily transfer data from one server to another by simply copying binary files (tables) of databases.
InnoDB is used in modern versions of MySQL as the default engine.
Unlike MyISAM, InnoDB supports transactions and foreign keys. Percona Server uses its own engine, XtraDB, which is fully compatible with InnoDB. Data in InnoDB / XtraDB is cached. When most of the data is read from the cache, InnoDB / XtraDB performance is several times higher than that of MyISAM.
Many articles have been published on comparing MyISAM with InnoDB / XtraDB, as well as MySQL with its forks (see, in particular, the performance test here) We will not go into theoretical details and limit ourselves to practical advice: MyISAM should be chosen only in cases where a full-text search is needed. InnoDB / XtraDB will do just fine with all other tasks. By the way, in MySQL / Percona Server 5.6+, full-text search for InnoDB is already supported .
DBMS configuration optimization
As the site develops, the amount of data in the database will grow, and there will be a need to change the database settings. In order to ensure the optimal functioning of the site, it is advisable to regularly check how the current configuration of MySQL is optimally configured. This verification is easiest to carry out using special scripts, the most famous and popular of which is mysqltuner.pl. It can be downloaded using the following commands:
$ wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl $ chmod + x ./mysqltuner.pl $ ./mysqltuner.pl
This script collects MySQL statistics and provides recommendations for improving existing settings.
Configure the web server
Apache Options
Apache settings are stored in the /etc/apache2/apache2.conf file. In the Apache configuration file there is such a parameter as max_clients - the maximum number of processes that are launched to process client requests in parallel. At first glance, it might seem that you need to set the maximum value for this parameter. In real practice, however, things are different.
Suppose one Apache process can consume 20 MB of RAM. If the parameter max_clients is set to 200, then with a peak load under all processes, 200 × 20 MB = 4 GB of memory will be required - and this is only under Apache! As a result of running out of memory, even the simplest queries will run extremely slowly. And the software on the server may stop working.
Therefore, setting the max_clients parameter too large is not advisable. If the number of requests exceeds the set value, then all these requests will be queued and processed as soon as busy processes are freed.
In order to improve performance, it is also recommended to disable keepalive connections by correcting the corresponding line in the configuration file:
Keepalive off
Backend + Frontend = Apache + Nginx
Any more or less heavily loaded web project should have a multi-level architecture (we already wrote about this ). For most projects based on Wordpress, the two-level architecture of Backend - Frontend is quite suitable. We recommend using the following bundle: as a backend Apache, as a frontend - Nginx.
However, another option is also possible - php-fpm as the backend, and as the frontend - the same Nginx (see the configuration instructions, for example, here and here) . Many publications claim that the php-fpm + Nginx bundle is faster or consumes much less memory. However, it is hardly possible to unequivocally agree with these statements.
Tests published on the Internet should be treated with a healthy amount of skepticism: often php-fpm + Nginx shows better results only because Apache was not configured properly (see, for example, the test report and its critical analysis ; see also interesting discussion here ). Based on our own experience, we can say that for most Wordpress projects the combination of Apache + Nginx is quite suitable. The choice of a solution should be based not only and so much on the increase in productivity, but on the specifics of the tasks to be solved and considerations of technological convenience. And Apache, in our opinion, is more flexible in configuration. It can be used both as a separate web server, and as a backend for Nginx, and as a frontend for php-fpm.
The general scheme of work looks like this: Nginx receives requests from users, which are then either transmitted by Apache or processed independently. Apache requests will be sent related to the processing of dynamic content - for example, php scripts. Nginx independently processes requests for the return of statics - for example, graphics, JS, CSS, text files, XML files.
Having processed the request and passing the contents of Nginx, Apache disconnects and proceeds to process other requests. Thanks to this, the work is significantly accelerated (which is important, for example, with a slow Internet connection).
In addition, the distribution of dynamic requests can be accelerated using the Memcached server (see, for example, the installation and configuration instructions here ).
We provide security
To expand the functionality of Wordpress, numerous plugins are used. Various vulnerabilities are constantly detected in these plugins, and because of this, some system administrators are somewhat biased towards it. Wordpress-based sites do indeed often become targets for attacks, but over time, developers improve plugins to eliminate existing security flaws. Below we will give some more tips for setting up Wordpress, with which you can make the site less vulnerable.
Protect yourself from malware and script vulnerabilities on the server on which Wordpress is installed. We recommend using the ClamAV + Maldet scanner. Instructions for installing and configuring AV can be found here . You can also use the program to search for vulnerabilities.WPScan .
Change the table prefix in the database. By default, the wp_ prefix is set in the Wordpress database. This simplifies the use of vulnerabilities with MySQL injection: if the table name is known, it is much easier to insert malicious code into it, change the information in it, or delete it altogether. New versions of Wordpress have the ability to select a prefix during installation.
If you are using an earlier version of Wordpress, you can change the prefix using specialized plugins. The most famous and popular is the Prefix Changer. However, it should be noted that many of these plugins do not always work correctly, so it is recommended that you back up the database before using them.
Move the wp-config.php file.The wp-config.php file contains important Wordpress settings that you want to protect against unauthorized access. By default, this file is saved in the root directory, but you can move it to the directory above. If wp-config.php is not found in the root directory, Wordpress will automatically search for it.
Obtain an SSL certificate and enable SSL encryption. To do this, add the following lines to the wp-config file:
/ * Enable SSL Encryption * /
define ('FORCE_SSL_LOGIN', true);
define ('FORCE_SSL_ADMIN', true);
Delete Wordpress version information. If an attacker finds out that you are using an outdated version of Wordpress, then it can take advantage of the existing vulnerabilities and hack your site. Therefore, version information is best removed.
First, you need to delete the file: yoursite/readme.html , from which you can easily find out which version of Wordpress you are using.
You can also find out about the version used from the header.php file, which is located in the theme folder. It contains the following line:
<meta name = "generator" content = "WordPress" />
You can delete this entire line. If there is no such line in the header.php file of your theme, then most likely it is inserted automatically by Wordpress when the wp_head () function is called. In this case, you can delete version information from the section by adding the following code to the functions.php file:
remove_action ('wp_head', 'wp_generator');
function selectel_remove_version () {
return '';
}
add_filter ('the_generator', 'selectel_remove_version');
Change the security keys. The wp-config.php file mentioned above has a section with security keys. It looks like this:
define ('AUTH_KEY', '');
define ('SECURE_AUTH_KEY', '');
define ('LOGGED_IN_KEY', '');
define ('NONCE_KEY', '');
Keys are used to hash passwords. Very often, even experienced users do not pay attention to this section. Meanwhile, changing the security keys is quite simple: just go to https://api.wordpress.org/secret-key/1.1 and copy the generated keys to the wp-config.php file. It is enough to carry out this procedure only once during the initial setup of the site.
Restrict access to the wp-content and wp-includes folders. For security reasons, it is recommended that you block access to the contents of the wp-content and wp-includes folders. You need to block access to any files except graphics, JS and CSS. To do this, create a .htaccess file in each folder and put the following code into it:
Order Allow, Deny Deny from all Allow from all
Create an empty wp-content / plugins / index.html file. Thanks to this, information about which plugins you use will become unavailable. Wordpress plugins may contain vulnerabilities and can be exploited by cybercriminals.
To make the listing inaccessible, you can also add the following line to the .htaccess file stored in the plugins folder:
Options -Indexes
Restrict access to the wp-admin folder.
To restrict access, you need to create a .htaccess file in this folder and put the following code into it:
AuthUserFile / dev / null AuthGroupFile / dev / null AuthName "Access Control" AuthType Basic order deny, allow deny from all # indicate, for example. Home computer IP allow from # here we indicate the address of one or more IP addresses from which we will write a blog at work allow from allow from
Restricting access to a specific set of IP addresses is not always convenient. You can configure access to the wp-admin folder only with a password. To do this, create a .htauth file:
$ htpasswd -c /home/yourdirectory/.htauth
And put it one level above the / public_html / directory.
Then you need to create a .htaccess file in the wp-admin folder and put the following code into it:
AuthName "Admins Only" AuthUserFile /home/yourdirectory/.htauth AuthGroupFile / dev / null Authtype basic require user <username>
Conclusion
Setting up even such a simple and intuitive CMS as Wordpress is a rather complicated task and contains a large number of nuances that even experienced users do not always pay attention to. We hope that the above recommendations will be useful to you. For our part, we are always ready to assist in setting up and optimizing complex projects on Wordpress as part of our new package of server administration services .
The list of recommendations given in this article, of course, is far from complete. We will be glad if in the comments you express your comments and share your own experience in optimizing projects on Wordpress.
Readers who cannot post comments here are welcome to join us on our blog .