Virtual Private Server Use for WordPress Blog Performance Optimization
Scripts Resource Intensity
Nowadays having a personal website is as common as having a cell phone. Some people use cell phones for just giving and receiving calls and messages and some cannot simply imagine their mobile telephony device without a camera, an MP3-player and so on. It really is likewise about the websites: some website owners use their hosting accounts to bring up pages on the web and use email at their own domain. The others want their websites to be an ultimate public project, which would support many options starting from integration with social networks and ending with, but not limited to provision of downloadable content.
The way the sites are built is a question of demand, of course. But this question raises another one in turn – a question of approach. Many website owners start with shared hosting but then face with the problem of resource overuse, as their projects keep developing. And that’s where the question of approach becomes essential – those who take such issues seriously usually decide to upgrade in order to avoid temporary suspension due to excessive resource usage.
Of course, the website owner may not always realize the influence of his/her particular account on the entire server. On the other hand, server administrators are always glad to assist with the resolution of the problem. Those suspensions are mostly a preventive measure, which doesn’t let the entire server go down. For example, our team is always open for a dialogue and we co-operate with our Customers to find out the way to get the issue resolved. However, if it is definitely not about some particular script or module which is enough to be disabled to let the account keep working on the shared server – an upgrade is the next step.
VPS as a Hosting Ground for Resource Intensive Websites
Several years earlier the word “upgrade” would definitely mean a setup of a dedicated server, which would be tens times more expensive, than a shared hosting plan you used to have. Modern technology, however, has introduced a more liberal solution – Virtual Private Server (VPS). Those virtual servers are containers, created by means of virtualization software on physical servers. Current platforms allow a VPS web hosting user to obtain almost the same level of performance as the server-carrier provides, which means that a user can get a dedicated server, though a virtualized one, for a significantly cheaper price.
A virtual server has the following key advantages, which are to be considered during the upgrade:
1. Isolation – none of several virtual servers on the carrier influences each other. No limitations are set.
2. Full root environment – the user is provided with the maximal administration privileges.
3. No hardware dependencies – server does not require file system checks and RAID array rebuilds after reboot.
As you can see, a VPS resolves the main concern of a shared hosting account user – mutual user dependency. The thing is that shared servers have such strict limitations primarily due to the problem of even resource distribution, i.e. those limits create fair equal conditions, which let any user run his/her applications without abusing the other accounts. This equality is also guaranteed on a server software level – all major services, like Apache, MySQL and PHP are configured in a standard way and can be slightly tuned up only on a user level by means of local configuration files (e.g. .htaccess, php.ini, etc.).
VPS web hosting, however, provides each user with isolated environment. This means, that there is no one to share resources with, i.e. there are no limits and that any server software may be tuned up according to the peculiarities of the hosted script/application.
If you still host your website on a shared server but decided to move to a VPS, take a look at the plans we offer at SiteValley. However, if you think a VPS is not enough for you, feel free to check our offers for cheap dedicated server hosting. Further tips will be applicable to a dedicated server as well.
Optimizing your WordPress Blog Performance
There are many scripts which require certain tune up. The more tasks a script is to carry our, the finer the tune up should be. As an example we take WordPress blogging tool, which is known for its resource usage peculiarities and a wide range of available plug-ins.
Surely, WordPress is one of the greatest scripts on the Web. This blog tool lets you create a nice and usable website by means of a user-friendly easy-to-comprehend interface. Its basic configuration is fine to be hosted on a shared hosting server and we offer a special plan Pro Hosting with WordPress script installer to those, who would like to start their own blog. Still, this platform is a rather resource intensive one, so depending on your goal and means of project realization, you may need to have your account upgraded.
Of course, it is essential to find out, what exactly makes WP resource intensive. Primarily it is the way, it works with the databases. Below you can find an example of a MySQL request created by one user, who is viewing one WordPress page:
3 Query SELECT option_name, option_value FROM wp_options WHERE autoload = ‘yes’
3 Query SELECT option_value FROM wp_options WHERE option_name = ‘rewrite_rules’ LIMIT 1
3 Query SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts WHERE 1=1 AND wp_posts.post_type = ‘post’ AND (wp_posts.post_status = ‘publish’) ORDER BY wp_posts.post_date DESC LIMIT 0, 10
3 Query SELECT FOUND_ROWS()
3 Query SELECT t.*, tt.*, tr.object_id FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON tt.term_id = t.term_id INNER JOIN wp_term_relationships AS tr ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy IN (‘category’, ‘post_tag’) AND tr.object_id IN (10) ORDER BY t.name ASC
3 Query SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (10)
3 Query SELECT * FROM wp_posts WHERE (post_type = ‘page’ AND post_status = ‘publish’) ORDER BY menu_order ASC
3 Query SELECT option_value FROM wp_options WHERE option_name = ‘page_for_posts’ LIMIT 1
3 Query SELECT * FROM wp_users WHERE ID = 1 LIMIT 1
3 Query SELECT meta_key, meta_value FROM wp_usermeta WHERE user_id = 1
3 Query SELECT * FROM wp_comments WHERE comment_post_ID = 10 AND comment_approved = ‘1’ ORDER BY comment_date_gmt DESC
3 Query SELECT * FROM wp_comments WHERE comment_post_ID = 10 AND comment_approved = ‘1’ ORDER BY comment_date_gmt DESC
3 Query SELECT * FROM wp_posts WHERE (post_type = ‘page’ AND post_status = ‘publish’) ORDER BY menu_order, post_title ASC
3 Query SELECT t.*, tt.* FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON t.term_id = tt.term_id WHERE tt.taxonomy IN (‘category’) ORDER BY t.name ASC
3 Query SELECT wp_comments.* FROM wp_comments JOIN wp_posts ON wp_posts.ID = wp_comments.comment_post_ID WHERE comment_approved = ‘1’ AND post_status = ‘publish’ ORDER BY comment_date_gmt DESC LIMIT 15
3 Query SELECT COUNT(comment_ID) FROM wp_comments WHERE comment_post_ID = 12 AND comment_parent = 0 AND comment_approved = ‘1’ AND comment_date_gmt < ‘2010-02-22 16:54:11’
3 Query SELECT COUNT(comment_ID) FROM wp_comments WHERE comment_post_ID = 12 AND comment_parent = 0 AND comment_approved = ‘1’ AND comment_date_gmt < ‘2010-02-22 14:25:24’
3 Query SELECT COUNT(comment_ID) FROM wp_comments WHERE comment_post_ID = 12 AND comment_parent = 0 AND comment_approved = ‘1’ AND comment_date_gmt < ‘2010-02-08 18:51:45’
3 Query SELECT COUNT(comment_ID) FROM wp_comments WHERE comment_post_ID = 12 AND comment_parent = 0 AND comment_approved = ‘1’ AND comment_date_gmt < ‘2010-01-29 02:58:05’
3 Query SELECT COUNT(comment_ID) FROM wp_comments WHERE comment_post_ID = 12 AND comment_parent = 0 AND comment_approved = ‘1’ AND comment_date_gmt < ‘2010-01-29 00:23:01’
3 Query SELECT YEAR(min(post_date_gmt)) AS firstyear, YEAR(max(post_date_gmt)) AS lastyear FROM wp_posts WHERE post_date_gmt > 1970
3 Quit
MySQL queries of the *SELECT type are one of the most abusive as they go over all the databases to find the needed value. This results into aggressive disk subsystem and CPU usage. By the way, the log above was for a simple WordPress page, which had no add-ons or plug-ins, so you can imagine, what it is going to be, if WordPress is run full-throttle.
It is absolutely logical to search a way for optimization of such queries, as far as the fewer queries are produced, the more free CPU time is left for other server services. That’s what caching is used for. All you need is to edit your wp-config.php file by adding the following two lines there:
// Enable the WordPress Object Cache:
define(ENABLE_CACHE, true);
But this is minor SQL optimization. Another reason for WordPress issues is webserver overload, caused by simultaneous http requests. WP does not offer any other built-in caching tools and the one –WP Super Cache, which is available as a plug-in – is rather resource intensive, so it is allowed for use on VPS and dedicated servers only (AUP, p. 10.1). WP Super Cache is a static caching plug-in, which generates html files that are served directly by Apache webserver without processing comparatively heavy PHP scripts. This plug-in is one of the means to increase your WordPress blog performance significantly.
Still, this is not all what you can do for webserver optimization. Now you should edit your Apache configuration file (full path: /etc/httpd/conf/httpd.conf) as follows:
Note: Before you proceed with file editing, make sure you backed-up your configuration file.
# Timeout and Keepalive
Timeout 30
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 6#Maximum Client Connections
<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 512
MaxClients 512
MaxRequestsPerChild 4000
</IfModule>
Note: MaxRequestsPerChild parameter is a tricky one, so 4000 is not the fixed value, you may try a range from 1000 to 4000 to see, which configuration is better and leave it.
Note: #Maximum Client Connections may be not available in the configuration file, if “prefork” Apache module is not configured (if not, there’s a “worker mpm” module installed instead).
Once the file is edited, restart Apache with the following command: /etc/init.d/httpd restart.
Additionally you may consult more online guides on disabling those Apache modules, you are not using.
Such modules take CPU time and RAM to get loaded and then simply do nothing, while you can comment them out in the configuration file.
Another service to edit is PHP. Find a global php.ini file (should be located there: /usr/local/lib/php.ini) and copy it to the root folder of your WordPress. Open it for editing to set the following parameters:
;*Turn off for performance
register_globals = Off
register_long_arrays = Off
register_argc_argv = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off
;*Allow PHP to accept large data
post_max_size = 8M
file_uploads = On
upload_max_filesize = 8M
Conclusion
We really hope you find these tips useful. Those are not the only ones, of course, so you can find many other ways of WordPress optimization, which may come in handy. It is still advisable to consult your technical support team before making any changes to the essential services on your server and of course, do not forget to backup your initial configuration files.
Tags: Guide, Virtual Private Servers, VPS, Wordpress