When you work for an enterprise level company, things need to be accomplished at an enterprise level. So, that is why we have taken a variety of wordpress implementations, from basic to complex plugins and begun load balancing WordPress. To make things more complicated, the servers involved are not going to be in the same location.
Load Balancing, Why Do It?
- Redundancy
If one of your servers crashes, hangs ups or experiences a hiccup, you have another hot one ready to serve pages. - Server Speed
If you are overloading one server, obviously a second server will resolve some of the speed issues if you are having IO issues. This is only if you are TechCrunch or Huffington Post. - HTML Loading Issues
If you are far away from the server, yes it could take a long time to view a page. Ever wonder how long it takes to reach your website from Buenos Aires. If you wanted to know, look at a service like Gomez or Keynote. Not sure of any free services out there to tell you this, and if you find one definitely let me know the URL!
WordPress On Multiple Servers
I am sure Automattic has been doing this for the larger clients at a fee, and that is where some of their revenue is coming from, because this is where the pain kicks in, while implementing WordPress. If you have two servers that need to split the WordPress traffic load, this will work fine, as long as you can call them both the same name, with separate IP addresses. This is where the loadbalancer does its job. Not an expert at loadbalancing, but I have heard of an F4. Basically, it splits the load and sends web traffic either round robin or on some algorithm to each site. It can be tweaked if one box is acting up or doing something wrong. If there is extremely high volume of traffic, you could go to many boxes, but then you may want to look at cloud computing.
Load Balancing Across Multiple Locations
Now this is where the bigger issues come into play. For instance, if you were to creating multiple load balanced servers in different data center, including different international locations, you will have to deal with the issue of syncing of files and of syncing of either DB latency issues or distributed DBs.
The MySQL Database Issues
Sudden MySQL and pretty much every DB becomes an issue when you are running a site in mutiple locations. You can do it, and we are going to be running WordPress in a multi server environment soon, so we can experience the latency first hand. By latency, we are referring to a site in one city, let’s say Houston, and the DB in Los Angeles. That would mean every DB query would have to cross the country and there would be some delay in the query result arriving. This would also mean that there is a chance the site will be worse off than before the new remote servers go online, and what would be the point of that.
Solutions For The WordPress MySQL DB Issue
First solution to consider is Caching of content. Looking at wp-cache 2, and Super Cache, it is possible to have the individual sites create their own cache locally after one DB hit, or the first one after the cache times out locally. This would only make sense if you have a website with little dynamic content. This is good for web pages, but for rapidly changing blog comments or forums, it does not work, because it would mean it never will update proper. However, experimenting with this is a good thing, and will help.
The second solution is to come up with a way for the MySQL DBs to be sync’d on a regular basis, preferably offline. Possibly one way would be every hour or 5 minutes a script would kick off and check for any changes. The changes would be sync’d to the other DBs in the distributed network and you would be able to keep all the sites local MySQL and speedy. Good luck on this one. Maybe a plugin to do this, is the answer.