WordPress Projects: Optimization Tips

Today Wordpress is one of the most popular CMS. Originally conceived as a blogging engine, today it is used for many different types of sites, in particular, for news portals and online media. Wordpress runs corporate websites, educational and entertainment portals.

Wordpress is used by many of our clients, who quite often contact us with questions about setting up this CMS.
')
Detailed instructions for installing and configuring Wordpress on the Internet published a lot. In this article, we would like to touch on issues that most of 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 a number of recommendations to improve the level of security and stability. Ubuntu 12.04 is used in all examples.

Configuring the DBMS

Select DBMS

As you know, Wordpress requires MySQL for its work. Recently, alternative implementations (forks) of this database have become widespread, the most popular of which are Percona Server and MariaDB. Many installation instructions published online recommend using MariaDB.

We recommend using Percona Server, since this fork is more productive and stable than 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, 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

Choosing the engine: MyISAM or InnoDB?

The most popular engines in MySQL databases are MyISAM and InnoDB. If the engine is selected incorrectly, then problems with performance and consistency arise.

Consider the features of these engines in more detail.

MyISAM shows good results on SELECT samples, which is largely due to the lack of support for transactions and foreign keys. However, when modifying and adding records, the entire table is blocked for a while, which, with a large load, can cause serious delays.

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 transfer data from one server to another without any problems 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 XtraDB engine, fully compatible with InnoDB. The 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.

There are quite a few articles devoted to comparing MyISAM with InnoDB / XtraDB, as well as MySQL with its fork (see, in particular, the performance test here ). We will not go into theoretical details and confine ourselves to practical advice: MyISAM should be chosen only in cases when full-text search is needed. InnoDB / XtraDB will do an excellent job with all other tasks. By the way, in MySQL / Percona Server 5.6+ full-text search for InnoDB is already supported .

Optimization of DBMS configuration

As the site develops, the amount of data in the database will grow, and it will be necessary to change the database settings. To ensure optimal performance of the site, it is advisable to regularly check how optimally the current MySQL configuration is configured. It is easiest to perform such a check 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 the existing settings.

We 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 launched for parallel processing of client requests. At first glance it may seem that this parameter should be set to the maximum value. In actual practice, however, things are different.

Suppose a single Apache process can consume 20 MB of RAM. If the max_clients parameter is set to 200, then at peak load all processes will require 200 × 20 MB = 4 GB of memory - and this is only for Apache! As a result of lack of memory, even the simplest requests will be executed extremely slowly. And the software on the server may stop working.

Therefore, setting the max_clients parameter too large is not desirable. If the number of requests exceeds the set value, then all these requests will be queued and processed as soon as the occupied processes are released.

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 highly loaded web project must have a multi-layered architecture (we have already written about this). For most projects based on Wordpress, the two-tier Backend - Frontend architecture is quite suitable. We recommend using the following bundle: as the Apache backend, as the frontend - Nginx.

However, another option is possible - php-fpm as a backend, and as the front end - the same Nginx (see configuration instructions, for example, here and here) . In many publications it is argued that a bunch of php-fpm + Nginx is faster or consumes much less memory. With this statement, however, one can hardly agree unequivocally.

Tests published on the Internet should be treated with a healthy skepticism: often php-fpm + Nginx shows the best results only because Apache was not configured properly (see, for example, testing report and its critical analysis ; see also curious discussion here ). Based on our own experience, we can say that for most Wordpress projects, the Apache + Nginx combination is fine. The choice of the solution should be based not only and so much on the productivity gain, but on the specificity of the tasks and considerations of technological convenience. And Apache, in our opinion, is more configurable. It can be used as a separate web server, and as a backend for Nginx, and as a front-end for php-fpm.

The general scheme of work is as follows: Nginx accepts requests from users, which they then either transmit to Apache, or process them themselves. Apache will be transmitted requests related to the processing of dynamic content - for example, php-scripts. Nginx independently handles requests for the return of statics - for example, graphics, JS, CSS, text files, XML files.

Apache processing the request and transferring the contents of Nginx, is disabled and the transition to the processing of other requests. Due to this, work is significantly accelerated (which is important, for example, with a slow Internet connection).

In addition, the distribution of dynamic queries can be accelerated using the Memcached server (see, for example, the installation and configuration instructions here ).

We provide security

Numerous plugins are used to extend Wordpress functionality. In these plugins, various vulnerabilities are constantly detected, and because of this, some system administrators treat it somewhat biased. Wordpress-based sites do often become a target for attacks, but over time, developers will improve plug-ins, eliminating existing security holes. Below we will give some more tips on how to customize Wordpress, with which you can make the site less vulnerable.

Protect yourself from malware and vulnerabilities in scripts 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 WPScan to scan for vulnerabilities.

Change the prefix of the tables in the database. By default, the wp_ prefix is ​​set in the Wordpress database. This simplifies the use of vulnerabilities with MySQL injection: if you know the name of the table, it is much easier to insert malicious code, change the information in it, or delete it altogether. In new versions of Wordpress, it is possible to select a prefix during installation.

If you are using an earlier version of Wordpress, then 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 plug-ins do not always work correctly, so before using them it is recommended to save a backup copy of the database.

Move the file wp-config.php. The wp-config.php file contains important Wordpress settings that you want to protect from unauthorized access. By default, this file is saved in the root directory, but it can be moved to the directory above. Not finding the wp-config.php file in the root directory, Wordpress will search for it automatically.

Get 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);

Remove the Wordpress version information. If the attacker finds out that you are using an outdated version of Wordpress, then he can take advantage of the vulnerabilities and hack your site. Therefore, version information is better to delete.

First, you need to delete the file: your_site / readme.html , from which you can easily find out which version of Wordpress you are using.

You can also find out about the version you are using from the file header.php, which is located in the folder with the theme. 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 you call the wp_head () function. In this case, remove the 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 security keys. In the wp-config.php file mentioned above there is 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. This procedure is sufficient to carry out only once during the initial configuration of the site.

Restrict access to wp-content and wp-includes folders. For security reasons, it is recommended to close access to the contents of the wp-content and wp-includes folders. It is necessary to close access to any files, except graphics, JS and SS. To do this, in each folder, create a .htaccess file 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 what plugins you use will become inaccessible. Wordpress plugins can contain vulnerabilities, and attackers can take advantage of this.

To make the listing unavailable, 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 place the following code into it:

  AuthUserFile / dev / null
 AuthGroupFile / dev / null
 AuthName "Access Control"
 AuthType Basic
 order deny, allow
 deny from all
 # specify, for example.  IP address of the home computer
 allow from 
 # here we specify the address of one or more IP addresses from which we will write to the 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 by password. To do this, create a .htauth file:

  $ htpasswd -c /home/yourdirectory/.htauth

And place 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 quite difficult and contains a lot of nuances that even experienced users do not always pay attention to. We hope that these 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 is, of course, far from complete. We will be glad if you make comments in the comments and share your own experience of project optimization on Wordpress.

Readers who can not leave comments here are invited to our blog .