OpenX Tips

So, business is booming, and you are approaching your OpenX installation’s maximum capacity — you know this, because you measured your system capacity. You know that it’s time to scale your OpenX installation.

Or, perhaps you have no idea what you system’s maximum capacity is, but you have noticed that your system is a little bit slower than it used to be, and you think that scaling your OpenX installation might be a good idea¹.

How do you go about scaling an existing OpenX installation?

There are essentially two different options for doing this simply.

Vertical scaling

Vertical scaling is the easiest way of scaling your OpenX installation — simply upgrade your existing server (perhaps by adding more RAM or changing the hard drives so that they have faster I/O) or move your OpenX installation onto a larger, faster server.

Certainly, this will not be a hassle-free process — performing hardware upgrades or migrating services from one server to another are never going to The Guru’s idea of a fun day’s work — but if you currently run OpenX on a single server, then it can be comforting to know that, after you have completed a vertical upgrade, you will still have a familiar, single server setup.

Unfortunately, the main drawback with vertical scaling is that sooner or later, depending on your budget, it will simply become too expensive to perform a vertical upgrade².

Simple horizontal scaling

Simple horizontal scaling as an approach where OpenX is scaled horizontally (that is, over multiple servers) at the delivery/UI server level, but where there is still only one database.

Using this approach, there are only four things that are different from a single-server installation of OpenX that you need to worry about:

1. Database access: In a single server installation, ensuring that OpenX can access the database is generally trivial, as all that is needed is a username/password. However, now that your delivery/UI servers are separate from the server that is running the database, you may need to update your database server’s accounts and/or permissions, to ensure that the OpenX code on the remote delivery/UI servers can connect to the database.
2. Load balancing: To distribute the task of banner delivery and OpenX UI access across all of your delivery/UI servers, you will need some form of load balancing solution.
3. Code synchronization: As OpenX is now installed on more than one server, you need to ensure that all servers remain synchronized with each other, so that when you make configuration changes, or perform an upgrade, you don’t end up with one (or more) of the servers in a different state from the others. This is relatively easy to achieve by using rsync, or a similar code synchronization system³.
4. Running maintenance: When OpenX is installed on more than one server, but you have a single, central database, it is important to ensure that only one server runs maintenance⁴. Pick one of your delivery/UI servers, and set up maintenance to run on just that server. Disable maintenance from running on all the other servers. It’s even more important to run maintenance manually in this kind of setup, otherwise the issues of not doing so will be increased, as a result of having more delivery/UI servers!

Of course, with this form of simple horizontal scaling, the central database server can become a bottleneck. If this happens, you can either scale your database server vertically, or you will need to consider using OpenX’s “distributed statistics” mode for horizontal scaling, which allows the database load to be (partially) distributed across multiple servers — however, scaling OpenX in this was is most certainly not a simple means of scaling, and is a topic for another day…

1. Assuming that you have at least tried basic performance tuning first! [↩]
2. Let’s face it, there are not many OpenX users that can afford to go and drop $50k or even more on a top-of-the-line server. [↩]
3. It is often easier to manage this process if you distribute banner delivery across all of the servers, while limiting UI access to one server, as this means there is only one UI server where changes can be made, and upgrades can be run. However, this of course also limits the level scaling you can apply to your OpenX UI service. [↩]
4. If all of your servers ran maintenance, and they all ran maintenance at the same time, this should not be an issue, as OpenX does have code in place to try and ensure that if you run more than one instance of maintenance at a time, it won’t matter; but it’s better not to do this, if you can avoid it [↩]