High CPU load of WordPress - CPU, server and hosting

Hi Hi. Often, bloggers and webmasters are faced with such a problem that sooner or later their projects begin to slow down terribly. Significantly increases the load on Hosting CPU, and traditional methods do not help in solving it at all. And today I would like to tell you about what to do if your WordPress site is slow and how to reduce the load on the server in this case.

In most cases, significant freezes and slowdowns on the site begin completely unexpectedly, and therefore panic naturally begins. In a state of fear, bloggers begin to “pick” their site, trying to save it from this unpleasant problem. But more often than not, such “rescue” ends in failure, even leading to the demolition of the site, without the possibility of restoration.

This is actually very deplorable, especially if the blog is more than one year old and has accumulated a lot of interesting and useful articles, and the visit counter numbers are more and more pleasing every day. Wouldn't you like to get into such a terrible situation? Then you are very lucky, I would like to protect you from bad things right now, and teach you what to do if WordPress freezes.

Just a couple of days ago, one blogger and information businessman, whom many know very well, contacted me - Dmitry Zverev, with a request to see the severe freezes on his blog. Naturally, I agree, this is my job, especially why not help a good person? 🙂

So, Dmitry sent me all the data from the site and hosting, and I started analyzing it. Imagine, average speed The site loading time was as much as 13 seconds.

Tough, isn't it? What can I say, in addition to such “speed”, the accessibility of the site was lame, sometimes the site opened every other time. In a word, it crashed catastrophically and refused to work fully. And the most interesting thing was that when logging into the admin panel there were even more problems!

This piqued my interest even more because I had never encountered anything like this before! “Well, let’s try, the harder it is, the more interesting it is,” I thought, and got to work.

First of all, I began to analyze the activated ones and see which of them load the site the most. I performed the analysis using a plugin called P3. If anyone is interested in learning more about him, subscribe to blog updates. I will definitely write about this in one of the following articles.

Thus, I discovered 2 plugins that loaded the blog more than others: LeadPages and NextGEN Gallery. But after disabling them and clearing the cache, absolutely nothing changed. And then the fun began. I started digging deeper and deeper to find the real reason this disgrace :)

After some experimentation and testing, I came to the conclusion that the hosting may be causing the problem. I wrote to Jino support, but I never received a clear answer or help. Therefore, I could only rely on myself and my many years of experience.

And so, after two days, and many attempts, including absolutely useless ones, the speed became as follows:

And besides this, constant malfunctions stopped and hosters stopped complaining about increased CPU load. Hooray! What I was striving for, I got it - mission accomplished.

But what exactly did I do and how did I manage to win? Let's go in order.

Reducing server load

1. First of all, I recommend that you read one of my first articles on increasing website loading speed using . In this article you will learn how to perform high-quality website optimization and its effective acceleration For full-fledged work. Also, in this article I demonstrate best services to check the speed.

But sometimes these tips are not enough, for example, as in the case of Dmitry. After completing all the speedup steps from that article, the site began to open even worse and the hosters began literally block access to it due to significant overload. Therefore, it was necessary to perform some other actions.

2. Often brakes appear due to script called WP-Cron. This script built into WordPress is responsible for scheduling tasks. For example, posting articles by time, automatically emptying the trash can, creating backup copy using a plugin, etc.

Everything seems fine, the thing is cool and all that, but the fact is that Cron creates very heavy load on .And sometimes hostings cannot withstand such a load and block access to the site. In this case, you need to disable this script and the load will decrease significantly.

But you should understand that the actions that you perform in automatic mode stop working, you will have to do them manually. But there is absolutely nothing complicated about this.

So, there are several ways to disable WP-Cron. The fact is that some of them (as was the case in my case) may not work, but others may.

1 way. Go to the root of your site via Ftp, for example through FileZilla, and open there a file called wp-config.php and add a new line:
Define('DISABLE_WP_CRON', true);
It is advisable to add it after the line:
Define('WPLANG', 'ru_RU');
Then save the file and rejoice, the script should be disabled.

But if this does not happen, then you need to use the following options.

Method 2. Again, in the root of the site you need to open a file called wp-cron.php, find the line:
Ignore_user_abort(true);
and comment it out (disable it) using two slashes. The output should look like this:
//ignore_user_abort(true);
We save the file and cron is disabled.

3. Next, you need enable zlib compression, which allows you to significantly speed up the site due to processing and compression php code. First of all, you need to write to the hoster and find out whether you have the zlib function enabled or not. If it’s connected, great, but if not, please turn it on. Then go to the header.php file and to the very top insert the following code:

We save the file and feel a significant increase in speed.

4. After which it is very important optimize the database using the plugin. Go to the admin panel, open the “Plugins” tab - “Add plugin” and enter “WP-Optimize” in the search, press Enter and install the first plugin.

Now our database is optimized, and this is another plus in the direction of speeding up the site.

5. Now our task protect your blog from Ddos attacks, because It is precisely such attacks that often become the reason for the “brainbreaking” of a site. To do this, firstly, I recommend installing a plugin called iThemes Security, I will talk about setting it up in the next article, and secondly, it is important to use blocking suspicious visitors using .htaccess.

I will not explain now how to look for such suspicious and malicious ones, because this is the topic of a separate article, but I will share with you a list of IP addresses that I was able to collect over some time. They are the ones who will need to be blocked.

Many WordPress site owners ask questions: “ Why is my site creating heavy load for hosting?" And if one half of these webmasters are to blame themselves ( a large number of unnecessary plugins, poor optimization), then the other half really can’t understand what’s going on.

So, brief instructions for the second half, how to reduce the load on hosting and further protect your WordPress site from hacking.

1) Close xmlrpc.php

xmlrpc.php is perhaps the most unnecessary file on the site, but it is often used to hack the site and create a load on it.

To file .htaccess on your site (at the root) add the following:

deny from all

In addition, you can go to the theme function file functions.php and paste the following code:

Add_filter("xmlrpc_enabled", "__return_false");

Now remember to remove traces of this function. Go to the file header.php your theme and delete the line of code that contains pingback and xmlrpc.php. Typically this line looks like this:

2) Close or limit the admin panel

Second reason high load is password selection. Hackers are trying to hack your admin by creating tons of requests. We put additional protection through the same .htaccess file.

2.1) If you are the only site administrator with a permanent IP address:

Create in a folder wp-admin.htaccess file and paste into it:

Order deny,allow deny from all allow from xxx.xxx.xxx.xxx

Instead of X we write your IP address. As a result, only you and no one else will be able to log into the admin area. They won't even be able to try.

2.2) If you are not satisfied with the previous option, you can simply further protect your admin panel (without a plugin):

To file .htaccess In the root of the site paste the following:

AuthType Basic AuthName "Private zone. Only for administrator!" AuthUserFile /home/p259227/www/site.ru/.htpasswd require valid-user SecRuleEngine Off

Site.ru - change it to yours.

Create a file in the root of the site (in the same place as .htaccess) .htpasswd

This file will contain additional login and password. This protection is done at the server level, so it is quite reliable. It is advisable to set a login and password different from the login and password on the site.

Open the file .htpasswd and insert the following line:

Where Login is your login, and then your password in a special encrypted form.

To generate your password in this form, you can use various online services, for example: htaccesstools.com.

As a result, you get a ready-made line (encrypted password) that you need to paste into .htpasswd

Good day, dear readers of the blog site. Today I want to talk about how to reduce the load on the hosting server created by . In other words, we will optimize this engine to reduce the load on the host server.

But you know what your project is called and it is not at all necessary to access the database when opening any of its pages. Therefore, after you have finally decided on the choice of template, you can safely replace the code sections in its files that implement queries to the database with specific names, paths, etc. ().

Thus, we will reduce the number of calls to the WP database when loading any of the blog pages, and this is no less. Now let's move from theory to specifics and see what can really be corrected.

First, you will need to access your theme files via FTP. They are in the folder:

/wp-content/themes/name of your theme

Let's start with what was already mentioned above - HEADER. I think that you are already familiar with Filezilla and FTP access to the host is not new to you. If not, then there is a search box at the top and it will be enough to enter the word “filezilla” or “notepad” there to get the most full information for these two extremely useful programs.

HEADER implements quite a lot of database calls, which can easily be replaced with static data or deleted altogether. At the very top you will probably see the following piece of code:

; charset=" />

No, of course, you don’t need to delete it, but you can modify it a little by removing unnecessary calls to the database:

Well, two negative requests is nothing, but nice. Further more. What else can be replaced or removed in HEADER? Let's list:

Delete the line with information about the installed number WordPress versions. It does not carry any payload and, moreover, is dangerous because Some hacking options are applicable only to certain versions, and from this line it is very convenient to find out the current version of your engine. This line usually looks like this: " />
Replace URL with yours CSS stylesheet file in your current theme to static. In the code this is the line: " type="text/css" media="screen" />

WP Tuner is installed on WordPress in the standard way, namely:

unpack the archive using an ftp manager, connect to your blog and upload the wptuner folder to the wp-content/plugins/ plugins folder on your hosting server
Log in to the admin panel and select the “Plugins” tab - “Inactive”
find the line with the WP Tuner plugin and activate it

If you encounter any difficulties when installing the WP Tuner plugin, you can refer to the article about solving possible problems with installing plugins. Now you can go to the admin panel and familiarize yourself with the settings of this extension (from the left menu, select Settings -> WP Tuner.

Actually, WP Tuner doesn’t have that many settings, and in order for this plugin to start showing the number of requests to the database when loading a page, you don’t need to change anything at all. You just need to go to the blog, but you need to be logged in as an administrator and open a page.

After it finishes downloading, scroll down and you will see the window of this extension under the footer. The figure below shows where you can see the number of database calls that have been made.

Ordinary blog visitors, naturally, will not see this disgrace introduced by WP Tuner, only the administrator, i.e. You.

But you can also see the number of requests to the database in WordPress without resorting to plugins. To do this, you need to access your blog files via FTP and open for editing, for example, the file:

/wp-content/themes/name_of_your_theme/footer.php

and somewhere in its contents you need to insert the following construction (the insertion location will determine the area where the number of queries to the database is displayed in the footer):

queries inseconds.

As a result, after loading the page, at the very bottom (in the footer area), you will see how many calls were made to the database:

Good luck to you! See you soon on the pages of the blog site

You can watch more videos by going to

15 Comments

1
Good thoughts, but everyone has them. I would like to read a possible solution to problems with database unloading by changing engine parameters
2
The main direction in significant WordPress optimization is server-side caching. I think you can read this in numerous other blogs. I don’t currently have a single website built on Wordpress, and accordingly I cannot describe the solution to optimization problems.
3
They always said online that VP was easy, and I believed it, even though I use Drupal in my life. Then in September I got a customer with the desire to “move from this buggy VP to Drupal.” It turned out the following:
1. The site ran on a VPS 500Mhz and 384 frames
2. Attendance is about 1000 hits per day.
3. All imaginable and inconceivable caches are included.
This whole system crashed consistently once a day, and was ungodly slow the rest of the time. The harsh and painstaking process of moving to Drupal began, as a result:
1. All materials were re-stretched.
2. Where the URLs were arranged, we left them; where they were not arranged, we made new URLs, 301 redirects to the old ones.
3. We moved with absolutely no losses. With the same functionality, and in some places even more.
Now the server's CPU load at the most difficult moments, when Gosha and Yasha arrive, does not exceed 30 percent, with caching disabled.
So, think about Drupal, it’s not as bad as everyone says.
Here is the patient - surlaterre.ru
4
I have nothing against Drupal, it’s a good system. My main complaint is that modern engines do not have a simple system for moving from another CMS while maintaining the old CNC system.
5
If we take the same transfer from a VP, then the existing module is transferred along with the VP URLs, but I transferred it with my module, everything was a little different for me
6
If this or that module is able to transfer any type of address that can be created using standard Wordpress tools, honor and praise to it, +1 to Drupal, but when I looked for something like this among the engines, I didn’t find anything, or I found it, but not everything was implemented.
7
In general, I can say: “There is nothing that is not portable,” if the topic is interesting, then welcome to ICQ/mail/Skype. Contacts on my website
8
I don’t know how you configured WordPress, server and caches. But I have sites running on WP that have 4,000 visitors per day on virtual machines and no problems. There are sites with 10,000 visitors per knock, but in private. There the load does not exceed 10% in peaks. So WP still rocks!
9
I'm currently learning MovableType. Despite its unusual nature (it uses perl and generates static html), this CMS is very lightweight and quite functional. Much faster than WP.
10
MovableType is good, but there is still little information about it in Russian.
11
I personally can’t figure out what kind of load there is. I’ve never had any major WP projects and I can’t check it myself. And no matter where I read, you won’t understand anything: some say wp rules, others say the engine is crap. In general, I have never seen anywhere what kind of load and what wp can withstand. One question remains: why then is wp in the ru zone in the leading positions? Maybe because of its simplicity?

How to reduce the load of a WordPress site on hosting and optimize the database?

I started asking this question after the Timeweb hosting support service wrote to me that my websites (there are 10 of them on this hosting) put an excessive load on the central hosting processes and the database. The increased load was partly due to a DDoS attack on one of my sites, and in addition to the fact that I have been hosting sites on this hosting for a long time (more than 1.5 years), and no work has been done to clean up garbage from or optimize databases did not conduct. But a website can be compared to a computer to some extent. If you do not clean it of unnecessary files, cracks and other crap, then the computer will over time eat up and require more resources, which will lead to slowdowns in its operation and frequent freezing. Therefore, you need to treat your sites with care and periodically take steps to optimize their performance.

How to reduce the WordPress hosting load and optimize the database (MySQL)?

I carried out small actions (which I will discuss later), which allowed me to significantly reduce the load on the hosting CPU. Generally speaking, we managed to reduce the load on the CPU from 30-40 to 0.34 - 0.50, and reduce the load on the database from 90 to 64-70.

As a result of the actions taken to optimize the database (MySQL), its size was reduced from 227 MB to 41 MB. As we can see, we managed to achieve significant results. What was done for this?

It turns out that any actions carried out in WordPress (be it publishing a new article, or simply adding a new plugin, etc.) have some effect on the database, increasing it in size. And the larger its size, the more different files in it that are in disorganized order - the greater the load on the hosting processes. Therefore, by working to optimize the database, you can significantly reduce these loads.

To optimize the database, you will need to install and activate the plugin - Optimize DB (read about how to install plugins). Next, go to the “Tools” section - find the line “Optimize DB” and follow it. Now, to optimize the database on your website, all you have to do is click on the “Optimize Now” button.

These simple actions optimize your WordPress database (so to speak, organize the chaos in it and put everything on the shelves). To prevent the operation of this plugin from creating additional load in the future, you just need to turn it off. To optimize your WordPress database, once a week or once a month, go to the plugins section, activate the Optimize DB plugin and optimize MySQL (this is the database). And then turn it off again.

But to reduce the load on hosting, I didn’t limit myself to just working with the Optimize DB plugin. Significant work has been done to combat spam. A particularly large amount of spam has accumulated on several sites (a total of over 6 thousand pieces). Speaking about spam, I mean comments of a spammy nature, a large number of which also load the hosting. I deleted a lot of comments that were awaiting verification (more precisely, to completely delete them - I initially sent them to the trash, and then emptied the trash), and also cleared the spam folder. Recently, the “Invisible Captcha” plugin has helped me a lot. Thanks to it, spam is instantly sent to the spam folder, and from there all spam comments can be instantly deleted by emptying this folder.

I would also advise you to install the “WP Super Cache” plugin (if it is not installed), activate it, and enable caching. It will be especially useful if a lot of visitors have already begun to visit your sites. In the process, I installed it on a couple more sites. Thanks to caching, the load on hosting is also reduced.

This is how the work was done on 10 sites, which took me about 2 hours. But I achieved my goal - I managed to significantly reduce the load on WordPress hosting.

It is also worth noting that the more different ones are activated on a WordPress site, the greater the load. Therefore, use only those plugins that you need and disable those that you do not use.