OpenX Tips

As you may be aware, the OpenX ad server summarizes data and calculated priorities for Contract campaigns on the basis of the configured Operation Interval.

You may also be aware that it is the maintenance script that summarizes the data and calculates the priorities. But how does this script run? There are two different ways — either automatically, or manually.

By default, an out of the box OpenX ad server installation will be configured to run the maintenance script automatically. The OpenX admin guide lists some advantages to running the maintenance script automatically:

• Outstanding maintenance tasks are triggered by banner delivery;
• Enabled by default on new installations; and
• No need to create scheduled tasks.

However, there are also some disadvantages to relying on automatic maintenance, in The Guru’s opinion:

• Automatic maintenance is called from the “lg.php” and “avw.php” delivery scripts. Respectively, these are the scripts responsible for performing impression logging after banner delivery, and for delivery of banners for the Image and No Cookie Image zone tag types. However, you may have noticed that the XML-RPC zone tag delivery script (“axmlrpc.php”) is not mentioned here. In fact, delivery via XML-RPC, which does not use a logging beacon, will not trigger the automatic maintenance process — therefore relying on automatic maintenance when you are using XML-RPC delivery may deliver inconsistent results, as maintenance will not be triggered.
• As a result of needing to test for when maintenance needs to be run, and then actually running it, the “lg.php” and “avw.php” delivery scripts will not complete as quickly as when automatic maintenance is turned off. Although the OpenX ad server tries to minimize the effects as much as possible, there will nevertheless be some users that occasionally experience a delay in the scripts completing when visiting your website.
• Finally, if you have a low volume site, it is possible that some Operation Intervals will not have the automatic maintenance script run at all. This can lead to some odd campaign priority values, as the script has been designed to run each and every interval.

As a result, running the maintenance script manually is The Guru’s preferred method. This is very easy to set up in crontab, as the OpenX admin guide shows.

However, once you have set up a crontab job to run maintenance manually, you should also update your OpenX configuration, to obtain the maximum benefits. While working as the Administrator account, go to Configuration > Maintenance Settings and then disable the automatic maintenance system — this will ensure the delivery scripts do not need to test to see if maintenance has been run recently, and will ensure you get the maximum performance from your delivery scripts.

OpenX with automatic maintenance fully disabled.

Once you have done this, again while working as the Administrator account, go to Configuration > Maintenance, and OpenX will report the current maintenance script configuration. (Please note that you may need to wait for the end of the current Operation Interval to see the current settings.)

Finally, don’t forget to update your crontab entry to run the maintenance script once per Operation Interval, if you have opted to change the value from the default!

One of the least understood configuration options in OpenX is the “Operation Interval” setting. What is it, and what does it do?

Operation Interval in the Maintenance Settings

The first and foremost thing to know about the Operation Interval is that it is not a means of changing how often statistics will be updated in the user interface. OpenX, no matter what version you have installed, will only ever update the statistics in the user interface once per hour. That is it — end of story, end of discussion. Changing the Operation Interval to a value less than 60 minutes will not change this, and if you modify the Operation Interval setting expecting this to be the case, then you will be sorely disappointed.

So, if this is the case, what is the Operation Interval?

The Operation Interval is the mechanism by which OpenX performs internal statistics data aggregation and is the basis on which priority calculations are performed. That is:

• Statistics data is logged based on the Operation Interval (for OpenX 2.8, anyway);
• Statistics data is summarized and stored based on the Operation Interval; and
• Priority values for Contract Campaigns are calculated on the basis of the Operation Interval.

So, given that the Operation Interval is something that only relates to OpenX’s internal operations, why would you want to change it?

To answer this question, you need to understand the two effects that reducing the Operation Interval from the default value of 60 minutes has. (The Operation Interval can only be set to 5, 10, 15, 20, 30 or 60 minutes.)

Firstly, because data aggregation is performed using the Operation Interval value, if you reduce the value from the default of 60 minutes, then OpenX will need to store more data rows. This is because if the Operation Interval is reduced, then there are more Operation Intervals per hour, which means there will be less data aggregation based on the Operation Interval, and so more data rows that need to be stored. As the Operation Interval is the basis by which data is summarized and stored in the “data_intermediate_%” and “data_summary_%” tables in OpenX, which account for most of the database size, then you can expect that an OpenX installation with an Operation Interval of 30 minutes would require twice the database storage as an equivalent OpenX installation with an Operation Interval of 60 minutes¹.

Secondly, because the maintenance process which calculates Contract Campaign priority values does so on the basis of the Operation Interval, if you reduce the value from the default of 60 minutes, then the OpenX maintenance process will be required to perform more work to calculate the priorities. This is because the maintenance script calculates a priority for every active banner/zone link in the system for every Operation Interval, so if the Operation Interval is reduced, then there are more Operation Intervals per hour, which means there are more priority values to be calculated. The part of the maintenance script that calculates priorities for Contract Campaigns would be expected to take at least twice as long to run on an OpenX installation with an Operation Interval of 30 minutes than on an equivalent system with an Operation Interval of 60 minutes.

So, given the increase in database size and the decrease in performance of the maintenance script that comes with reducing the Operation Interval value, why would you ever change the Operation Interval from the default value of 60 minutes?

The answer is that if you run a very high end OpenX installation, having the Contract Campaign priority values updated only once per hour may sometimes not be enough, and you really do need these priority values updated every half an hour, or every 15 minutes, or maybe every 5 minutes. Be aware, though, that you will need some seriously expensive hardware if you expect to be able to run a large OpenX installation with an Operation Interval of 5 minutes².

Of course, if you do change the Operation Interval value, don’t forget:

• You need to update your system crontab so that the maintenance script is run once (and only once) per Operation Interval. There’s no point in setting your Operation Interval to 30 minutes, so that Contract Campaign priorities can be updated more often, and then not running the maintenance script every Operation Interval to do so!
• You should review your banner delivery cache setting, as there is no point in calculating the Contract Campaign priorities more often, only to have these values ignored due to a long cache value.

Finally, it is worth noting that if you don’t actually run any Contract Campaigns, then there is no point in reducing the Operation Interval from the default of 60 minutes, as there will be no benefit for you at all in this situation!

1. Note, however, that OpenX does not update previously logged and summarized data when you change the Operation Interval — the new value only applies to data logged and summarized after you make the change. So, if you’ve had the Operation Interval set to 30 minutes, changing it back to the 60 minute default will only mean that you will save space on all new data. [↩]
2. If you do have an Operation Interval value that is less than 60 minutes, you should probably review this value. Is it really necessary to have it lower than 60 minutes? Is the additional database space required really worth the benefits? Is the maintenance script actually able to complete running within the defined Operation Interval time, or is it taking longer than the Operation Interval? If so, you are not really obtaining any benefits, and you are probably causing issues by not running the maintenance script completely and fully every Operation Interval. [↩]

The Guru was browsing through a list of old links the other day, and came across an article on optimizing MySQL’s InnoDB storage engine. It’s definitely worth a read if you’ve never seen it before, but if you’re just after the high level summary:

• Add more memory to your server. Memory is good.
• If you have lots of memory, don’t forget that you should be running a 64-bit O/S, with the 64-bit version of MySQL, if you are going to be able to utilize that memory!
• The OpenX ad server is a write intensive application, so RAID-5 is bad. Very, very bad. Use RAID 0, or RAID 10.
• Tune your InnoDB settings. Remember, tuning is a process of measurement, followed by making a change, and then re-measuring.

If you are using the OpenX ad server to display banners on your website, then you are almost certainly also interested in viewing the details of the users who visit your website.

To obtain this information, some people use third party services like Google Analytics, which collects data via a tag that is inserted into a website’s pages. Other people download and install Piwik, which also uses a tag inserted into a website’s pages. However, many people still use older tools like AWStats or Webalizer to analyze their web server log files instead.

If you are using a web server log analyzer, then you should keep in mind that the calls to OpenX to request, display and log banners will probably end up being added to your web server log file¹. As a result, if you are using a tool like AWStats or Webalizer, you should consider updating the configuration of the log file analyzer to ignore, or otherwise separate out, the OpenX ad server log entries, otherwise your page hit information in these tools will be greatly over-stated.

1. This will depend on exactly how OpenX is installed, and how your web server logging has been configured [↩]

A question that is often asked about the OpenX ad server is how to move the installation. Generally, this means one of two things — either how to move the installation from one server to another, or how to change the domain name that OpenX is installed on.

Moving server

Moving an OpenX ad server installation from one server to another is a relatively straightforward task, provided you don’t want to get too fussy and technical about it. The following approach for moving an OpenX installation to a new server is a simple, quick and easy way to get an installation moved.

• Ensure that your new server is set up with MySQL, a web server, PHP, etc. and is configured and working¹.
• Backup your OpenX database on the old server.
• Restore the database on the new server².
• Backup the entire OpenX ad server directory on the old server.
• Restore the entire OpenX ad server directory on the new server. Double check that the read/write permissions of the files have not been altered³.
• If required, backup the entire OpenX banner directory on the old server.
• If required, restore the entire OpenX banner directory on the new server. Double check that the read/write permissions of the files have not been altered⁴.
• Test logging into and using OpenX, on the new server.
• Test banner delivery on the new server.
• Change to use the new server in production!

Unfortunately, this approach does have a down side, in that once the OpenX database has been backed up in the second step, any changes to the database, including all data recorded by OpenX for banner delivery on the old server while the migration is “in progress”, will be lost.

Moving domain

Moving an OpenX ad server installation from one domain to another is very straight forward.

• Change your web server software to the new domain.
• Re-name your OpenX configuration file. For example, if your OpenX installation used to be on “www.example.com” and you are moving it to “www.newsite.com”, you would have a configuration file in the OpenX “var” folder called “www.example.com.conf.php”, which needs to be re-named to “www.newsite.com.conf.php”.
• Edit the re-named configuration file. In the [webpath] section, update the admin, delivery, deliverySSL, images and imagesSSL sections to use the new domain.
• Edit any other configuration files, including the “default.conf.php” file. These files may contain a “realConfig” item, which is a reference to the “master” configuration file. Update to the new domain name as required.

Moving server and domain at the same time

The Guru does not recommend that you do this. If you need to move server and you need to move domain name, do one first, and then do the other. Give yourself a day or two between each of the two steps, to really make sure that everything is working fine after the first step, otherwise if you end up with a problem, it won’t be possible to determine which change might be responsible!

1. You may want to perform a clean test installation of OpenX on the server to ensure that everything is working before proceeding with the move. [↩]
2. Don’t forget that you also need to ensure that all of your database users and permissions are set up on the new server as well! [↩]
3. You may also need to address file ownership, in the event that your new server’s web server configuration is different to the old server. [↩]
4. Again, check file ownership. [↩]