There are many types of clusters. The one I am going to cover in this post is a Web cluster. In other words, it is a cluster of several servers built to serve Web pages. It is a made up of Web servers, database servers, and file servers. You may ask, why not deploy only one server and install the Web, database, and file server? There comes a time when one single server cannot sustain the increase in traffic. The high number of visitors exceeds the capacity of the server. Be it processor power, memory availability, disk IOPS, or network IO.
Cluster
Building clusters is not for everyone. It is a complex engineering task. The complexity resides in making the whole, called cluster, accomplish the tasks efficiently and seamlessly. It becomes even more complex when one implements load balancing and database replication. Load balancing is the act of distributing tasks across two or more server with identical configurations. Database replication is the synchronization of database tables and meta data across two or more servers. Having two identical databases scales out well especially when it has been designated as the bottleneck.
Advanced Cluster
Too often I get asked, why not deploy a monster server with 32 cores and 64GB of memory instead of building a cluster? While such server might or might not sustain the traffic, there are many points that need to be thought out. The truth is such monster server is cost prohibitive. The price to value is too high and not worth it. The reason being there is currently no commodity server that can handle 32 cores. One would need a considerable budget. For much less, one can get a 32-core cluster. The other point to consider is the fact that the motherboard bus will not be able to sustain the throughput required for a high traffic server. It will not be able to seamlessly pull 64GB/s in and out of the memory system.
Another important point is disaster recovery, one would need another equally powerful server or a very aggressive (read extremely expensive) part-replacement contract. On the other hand, commodity hardware is so affordable one could keep a few spares without breaking the bank! Plus, a monster server will never handle Digg or Slashdot effects. The cluster, however, can scale to accommodate for traffic spikes.
Keep in mind that UNIXy builds clusters for current customers free of charge. The support and service is included with your purchased dedicated servers. Contact us today and we will go above and beyond to help out.
That’s all folks!
Be sure to read through the previous post for a quick introduction of IOPS.
Suppose that you’re copying a 10GB file from one disk to another. Let us assume that the only bottleneck is the disks’ own IOPS, which in case is 120. We are also only focusing on the disk where the data is copied to and assume that the other disk has no IOPS limitation. Because we are writing about 10GB, the majority of the IOPS are going to be writes and not reads.
We will also assume that the disk has a block size of 64KB. In other words we are copying a maxium of 64KB of data in one operation (120 operations per second). That gives us a sustained throughput of about 7MB/s (120 * 64 * 1024). For a 10GB file, it would take about 1462 (10GB/7MB) seconds to copy the 10GB file.
IOPS stands for Input and Output Per Second. It is essentially a value that describes the raw capacity of a data storage system. It sets an expectation for performance. Some storage systems are said to be capable 120 IOPS and others 340 IOPS or much more. The number of IOPS, for most disk systems, represents a count of a mix of data reads (Output) and writes (Input) per second. By that number, one can judge how fast and responsive a disk system can be. The numbers can be obtained by performing sequential or random operations on the disk system. The best representation is random operations since it reflects a real-life usage pattern.
Disk system manufacturers obtain IOPS numbers via benchmarking. There are tools that measure disk throughput and capacity by performing several read and write tests. For example, Iometer is a tool that can measure disk system performance and produce the IOPS value for such system. One needs to be aware of the fact that some manufacturers provide the IOPS based on cached read and write tests. The latter is a best case scenario test and does not reflect real-life usage.
So what happens when a system reaches the IOPS threshold number? I did use the word “reach” because in theory the disk system will almost never exceed the advertised IOPS. Back to the question, when the system reaches the IOPS threshold, it starts queuing requests. A busy queue generally indicates a bottleneck.
How often have you found yourself with a bottlenecked 2TB disk choking after barely putting a few files? Disk size capacity has no bearing on its IOPS capacity. A 2TB disk could have the same IOPS capacity as a 250GB disk! So when does one need to upgrade the disk system or the configuration at least? We shall post a new entry on this blog with the instructions.
That’s all folks!
There are a few server-grade processors in the market. The well-know ones are Intel Xeon, AMD Opteron, Intel Itanium, and Sparc. Core2Quad and Phenom are, for example, desktop CPUs. There is confusion as to what makes a server-type CPU different from a desktop counterpart. Besides the bus speed improvement, there is a fundamental difference that proves to be important especially if there is a lot at stake. At UNIXy, all servers we promote to production are either Intel Xeon or AMD Opteron processors. We have to offer the best quality components to our customers.
Before we delve into the main differences, there is one element that makes server processors stand out from the rest: validation. It is about the effort spent validating processors that differentiates desktop from server CPUs. As an analogy, it makes perfect sense that a passenger aircraft engine would require much more stringent validation than a car engine. The risk is undoubtedly higher for an aircraft engine. The same applies to server processors. A desktop processor is designed to cater to the needs of one person. On the other hand, there is much more at stake with a server processor!
Let us cover each point one by one.
Validation
Server processors are put through all kinds of tests under stressful conditions such as higher temperatures, strict environmental conditions, and high computing loads. The time spent performing these tests increases the costs and time to delivery considerably.
Dependable
Server processors are designed for reliability. For example, if your desktop processor were to somehow fail, the whole workstation becomes inoperable. Server CPUs have the smarts to be able to failover, in the case of a dual CPU server, without having to crash or shutdown. Granted, one would have to have a dual CPU configuration. It is important to note that desktop CPUs do not support dual processor configurations.
Self Correcting
Server processors have the circuitry in place to correct memory errors that can affect stability. The technology is called Error Code Correction (ECC). Some desktop configurations are also capable of ECC but the feature is not validated as is the case with server CPUs. Hence, my stressing the importance of validation first and foremost.
Higher trafficking
Server CPUs are designed with buses that operate at much higher frequencies (bandwidth). This means that they can process more data in and out of memory and other subsystems. Heat can be a concern for these buses as it impedes the flow of electricity and hence throughput. This is why server-grade processors have their matching powerful fan blowers.
That’s all folks!
In this post, we shall go through the steps required to optimize a WordPress blog. If you are a current customer of UNIXy (http://www.unixy.net), do know that we are happy to implement these changes for your blog free of charge. We are a fully managed provider so do take advantage of it. Contact us today!
There are times when hardware upgrades are not feasible due to either budgetary limits or time constraints. We understand that a WordPress blog could be hosted on a shared platform or dedicated server (VPS included) so we have written this post with that in mind. The first 5 steps can be completed in a shared environment where access to global configuration files is not permitted by the provider. All 10 steps can be completed on a dedicated server or Virtual Private Server (VPS).
WP Supercache is a WordPress plugin that once installed alleviates some of the burdens on the server. Essentially, it takes every visited PHP page, generates the HTML content, and stores it on disk for subsequent visits. This is called PHP caching. The performance gain is noticeable. Not only does it speed up requests and improves responsiveness but it also leads to less resource utilization on the server. To install WP Supercache, follow this link:
http://ocaoimh.ie/wp-super-cache/
2. Turn Autosave Off
The WP global variable AUTOSAVE_INTERVAL controls the how often WordPress auto saves posts as they are edited. For example, while editing or writing a new posts, WP could be automatically saving tens of copies of your posts to the main WordPress table. Each time such automatic save process kicks off the main posts table is locked in order to be updated, which prevents visitors from briefly accessing your blog. It also causes the load average to spike up. One could either increase the autosave interval or completely disable the functionality. To increase the interval to X number of seconds (the higher the better), do it as such inside the wp-config.php file:
define('AUTOSAVE_INTERVAL', 2200); // 2200 second autosave interval
To disable the autosave feature completely, create a simple plugin file and enable via wp-admin:
<?php
/*
Plugin Name: Disable Autosave
*/
function disable_autosave() {
wp_deregister_script('autosave');
}
add_action( 'wp_print_scripts', 'disable_autosave' );
?>
3. Disable Revisioning
This feature saves several revisions of the same post into the database. It clutters the posts table and ends up bloating indexes unecessarily. It’s best to disable this feature altogether if you don’t need it. Add this line to your wp-config.php to disable this feature:
define('WP_POST_REVISIONS', false);
No further action is needed.
4. Disable Non-Cacheable SQL Plugins
While it is a good idea to disable as many unneeded plugins as possible, it’s not always practical to do. But this step requires that you go through the code of each plugin and locate SQL queries that use the MySQL RAND() function. Because MySQL does not cache queries that use the random number generator function RAND(), there is a performance penalty associated with such plugins. For example, Random Post plugin uses RAND() in its select SQL, which forces the SQL to run against the database time and time again. You can locate the PHP scripts that use the RAND() function inside your plugin folder using this command:
grep -i "rand()" -r wp-content/plugins
Once located, one could either disable such plugin or replace MySQL RAND() with a PHP rand function. This way the PHP random function will be cached. The randomization will, however, not work as intended. The good news is that perceived functionality will not be much impacted.
5. Convert MyISAM Tables to InnoDB
The InnoDB engine is superior. There is no reason to run MyISAM anymore. Here is a Bash script that will convert all tables, that can be converted, to InnoDB. If you do not have access to a script shell, you can accomplish the same using phpMyAdmin or other MySQL management tools. Be sure to take a backup of the WordPress database before running this script. Also, be sure to define a maintenance window for this change as the alter locks up tables temporarily making the blog inaccessible:
#!/bin/bash
DBNAME="database";
DBUSER="user";
DBPASS="pass";
for t in $(mysql -u$DBUSER -p$DBPASS --batch --column-names=false -e "show tables" $DBNAME);
do
echo "Converting table $t";
mysql -u$DBUSER -p$DBPASS -e "alter table ${t} type=InnoDB" $DBNAME;
echo "Repair table $t";
mysql -u$DBUSER -p$DBPASS -e "repair table ${t}" $DBNAME;
done
Remember that those who are hosting their WordPress blog on a shared provider's server will not be able to proceed with the rest of the instructions. The following instructions require root-level access to the server and a technical understanding of systems.
6. Increase Query Cache
We have already covered MySQL's query cache thoroughly in a previous post. We will not cover this information here. Feel free to read our past post on our blog here:
http://blog.unixy.net/2009/06/improve-performance-with-mysql-query-caching/
7. Increase Sort Buffer Size
The MySQL sort_buffer_size variable controls the amount of memory that MySQL can allocate to dedicated to sorting. In other words, the more SQL queries that need to sort data the larger this value needs to be. But it shouldn't be that large as it can affect performance negatively. For example, you wouldn't fill up a large container of water only to find out you can't carry it for a mile. Instead, it's best to fill the container with only enough water. The same idea applies to sort_buffer_size. It is usually best to set it to slightly than the amount of L2 CPU cache. So for a Xeon x3430 with 8MB cache that would be around 6MB. The final my.cnf entry would then be:
sort_buffer_size = 6M
8. Increase Key Buffer Size
This configuration settings controls the amount of memory that MySQL can use to fit index blocks into memory while manipulating indexes. Increasing this value as much as possible (within reason) can improve performance greatly. It prevents MySQL from having to use the disk as temporary storage for its work area. Edit the main my.cnf file and put the following entry.
key_buffer_size = 128M
Restart MySQL for changes to apply.
9. Install and Configure Eaccelerator
Eaccelerator is a PHP cache module that ensures minimal CPU processing. It essentially renders PHP scripts once and saves the HTML output for subsequent calls. The benefits are important. Checkout the Eaccelerator Wiki on how to compile, configure, and run it here:
http://eaccelerator.net/wiki/InstallFromSource
10. Install Apache MPM Worker
Apache's Worker can have advantages over its default MPM Prefork. It is somewhat lightweight in the sense that it's threading based and can thus smoothout load average spikes when traffic increases. Worker requires a rebuild of Apache. Luckily, someone has already covered the steps requires to rebuild Apache with this MPM. Check it out here:
http://www.faqs.org/docs/Linux-HOWTO/Apache-Compile-HOWTO.html
With this step we conclude our crash course / guide to optimizing and improving WordPress. If you are a customer and would like to implement any of these recommendations, don't hesitate to ping us. I hope you enjoyed this post.
That's all folks!
