Here’s a great question from reader Komson, who writes:
Dear Guru,
We are using OpenX, and we are facing a problem — the server “goes down” at peak times.
Can you please shed some light on the maximum number of impression per hour, in general, you recommend you should not go over?
e.g. you should not serve over 150,000 impressions per hour.
Thanks in advance!
Here’s a question in response:
I’m planning a party. I’ve already bought some food. How many people can I invite?
It’s a somewhat flippant question, for sure, but hopefully you get the idea — it’s not possible to answer the question of how many people can come to the party without knowing more about the situation. To be able to accurately determine how many people can be invited to the party, you will need to know:
- How hungry do you expect the guests to be? Are they going to be happy getting just a few snacks, or will they will be expecting a full meal?; and
- How much food do you have for the party?
The same thing goes for answering the question about how many impressions per hour you can serve with OpenX.
First up, there’s the question of how much you want to “feed” to your guests. You may be aware that in computing, there are two different ways of measuring “performance”. There’s throughput, and response time.
Obviously, users of your web site won’t care about throughput — all they care about is response time, because they don’t want to sit around waiting for ages while your website loads. They want it to load now.
So, this is the question of how “hungry” your guests are — they want to be fed, and chances are they want to be fed now, but how much food do you need to ensure all of your guests are well fed? In this case, though, given that you’ve already bought the food (i.e. you’ve already got OpenX installed and set up ready to go on a server you’ve bought, or a hosted service you’ve paid for), its more useful to ask: how many guests can you invite to the party and still ensure everyone gets a good feed? That is, how many impressions per hour can you serve, and still ensure that your website loads quickly?
Of course, if we were really talking about food that you had bought for a party, then once you’ve decided how much you think people will want to eat, it would be pretty obvious by just looking at it how much food you have as to how many people you would be able to feed with it. Naturally, things aren’t quite so simple with an OpenX installation. How much “food” do you really have, so you can figure out how many people can come? That is, once you’ve decided what the maximum average response time you want your users to experience is, how many impressions per hour can you serve with your existing hardware before you will start having a response time that is worse than this?
Unfortunately, there’s only one way to figure this out — you have to measure it!
Luckily, OpenX have actually provided some scripts to take some of the pain out of measuring your ad server performance, but unfortunately, in the end, if you want to really know how many impressions per hour your OpenX installation can serve, while still keeping people happy, then unfortunately, you have to do some work.
Finally, before you dive into the task of measuring performance (or, if you’ve done so already, and you’re not happy with the results), don’t forget that the OpenX blog has three different articles that all relate to performance — these are definitely worth reading, especially if you have an OpenX ad server installation that is having performance issues!
If you have read The Guru’s article on how the banner delivery process works in the OpenX ad server, then you may have noticed that when a banner is delivered, two items of data are logged — a request, and an impression.
Understanding the difference between requests and impressions is important, and once understood, can provide you with some interesting insight into your OpenX banner delivery performance.
Requests and impressions in the OpenX database
Before diving into the difference between requests and impressions, it’s useful to understand where requests and impressions are logged.
If you are running OpenX 2.4 or OpenX 2.6, then requests are logged into the “data_raw_ad_request” table, while impressions are logged into the “data_raw_ad_impression” table.
If you are running OpenX 2.8, then requests are logged into the “data_bkt_r” table, while impressions are logged into the “data_bkt_m” table.
If you have never done so before, log into your OpenX database now, and take a quick look at the contents of these tables — but be careful! These tables, especially in the older OpenX 2.4 and OpenX 2.6 versions, can become very large, so running SQL commands on these tables may take a very long time and may even impact the performance of your server. As a result, it is generally worth limiting the number of rows you look at when you inspect these tables. For example, you might use the following commands:
OpenX 2.4 & OpenX 2.6
SELECT * FROM data_raw_ad_request ORDER BY date_time DESC LIMIT 20;
SELECT * FROM data_raw_ad_impression ORDER BY date_time DESC LIMIT 20;
OpenX 2.8
SELECT * FROM data_bkt_r ORDER BY interval_start DESC LIMIT 20;
SELECT * FROM data_bkt_m ORDER BY interval_start DESC LIMIT 20;
You should see some of your logged request and impression data.
If you are not seeing any request or impression data at all, have you delivered any banners recently? Try delivering some banners, and see if you can now see requests and impressions logged.
If you see impression data, but no request data, and you are using OpenX 2.4 or OpenX 2.6, do you have request logging enabled? Check:
- In OpenX 2.4: While logged in to OpenX as the administrator account, go to Settings, Main Settings, Statistics and Maintenance Settings, and check if the “Log an Ad Request every time an advertisement is requested” setting is enabled.
- In OpenX 2.6: While “working as” the “Administrator account”, go to My Account, Global Settings, Banner Logging Settings, and check if the “Log a request every time a banner is requested” setting is enabled.
Please be aware, however, that as OpenX 2.4 and OpenX 2.6 don’t have the newer, faster logging system that was introduced in OpenX 2.8, enabling request logging on an OpenX 2.4 or OpenX 2.6 system is likely to add significant additional load to your server. Think carefully before deciding to enabling this setting, and ensure that you monitor your OpenX server carefully after to make sure that the server’s performance is still okay.
Requests and impressions in the OpenX user interface
Now that you’ve seen the request and impression data in the OpenX database, and confirmed that it is being logged, it makes sense to ensure that this data can be seen in the OpenX user interface. By default, impression data will be viewable in the OpenX user interface, but request data is not viewable. To enable the ability to view request data in the user interface:
- In OpenX 2.4: While logged in to OpenX as the administrator account, go to Settings, Main Settings, Interface Defaults. Here you find a list of the various columns OpenX can display in the user interface’s various statistics screens. If it is not enabled, and you would like view requests in the statistics screens, check the “Show Requests column” setting for those account types you would like to be able to see requests.
- In OpenX 2.6: While “working as” the “Administrator account”, go to My Account, Account Preferences, User Interface Preferences. Here you will find a list of the various columns OpenX can display in the user interface’s various statistics screens. If it is not enabled, and you would like to view requests in the statistics screens, check the “Requests” setting. You can also change the order in which the viewable columns are displayed by changing the “Column Rank” numbers.
- In OpenX 2.8: While “working as” the “Administrator account”, go to My Account, Preferences, User Interface Preferences. Here you will find a list of the various columns OpenX can display in the user interface’s various statistics screens. If it is not enabled, and you would like to view requests in the statistics screens, check the “Requests” setting. You can also change the order in which the viewable columns are displayed by changing the “Column Rank” numbers.
Note that while OpenX 2.4 provides a facility for the administrator account to control which columns the four account types that exist in OpenX 2.4 can see, this is not possible in OpenX 2.6 and OpenX 2.8, where every account can modify which columns they want to view themselves — the above instructions simply change the master default account preferences for the “Administrator account” which all other accounts inherit their preferences from.
So, what’s the difference, and why do I care?
If you read the article on the banner delivery process carefully, you will note that a request is logged as soon as the OpenX ad server has determined which banner it is going to display. However, an impression is not logged until after the banner has actually been displayed.
You will notice, if you are logging requests and impressions, and displaying both columns in the user interface, that as a general rule, the number of requests are greater than the number of impressions. The difference between requests and impressions is generally referred to as the drop off rate. A “high” drop off rate is bad for two reasons:
- If your OpenX server is performing work selecting banners that are never shown, then your server is doing work that is irrelevant — so, your server performance is less than it could be, which is costing you money.
- If users are viewing your web site, and requesting banners, but the banners are not being displayed, then you are losing out on income — regardless of if your campaigns are paying you on a CPM, CPC or CPA basis, if the banners don’t show up, you won’t get paid.
So, what is a “high” drop off rate? There is no industry defined standard that The Guru is aware of, but anything more than 10% would certainly be cause for concern, and even drop off rates lower than this may represent a significant reduction of potential income for some sites. The only real rule here is that the lowest possible achievable drop off rate is desirable.
How do I fix a bad drop off rate?
This, of course, is the big question. The way to fix a bad drop off rate is to identify why banners are being selected for display, but are not actually being displayed, and to then act accordingly. Here are some of the top reasons for banners failing to display, and suggestions on how to address these issues:
Incorrect use of the Single Page Call tag
The Single Page Call tag calls OpenX just once, to obtain a banner for all of the zones that are to be displayed on a page. By default, the Single Page Call tag selects a banner for all of the zones in a website. So, if only some of the zones are going to be displayed on a page, then the tag needs to be edited before it is used, to ensure that banners are not selected that will never be displayed.
Large banner file sizes
If the file size of a banner is very large (e.g. large flash banners, etc.) then users with slower internet connections may “navigate away” from a page before the banner has finished downloading to their computer. Try to avoid using having very large banner file sizes, or, if this is essential, consider purchasing the MaxMind NetSpeed database, which will allow you to target large file size banners to users with faster internet connections only, while targeting alternative, smaller file size banners to those on dial-up connections.
Slow 3rd party banners
Many OpenX users will generate a large part of their income from ad networks, who supply an HTML tag that loads banners from the ad networks’ servers. It is an unfortunate fact of life that sometimes, the 3rd parties’ servers are not always as fast as would be desired. The only real option here is to monitor the drop off rate at the banner level in the statistics pages, and see if there are particular ad networks that are causing you persistent problems — and if there are, consider the income they generate. If they are not a major part of your income, perhaps dropping these ad networks may result in overall better income for your site.
Slow websites and poor banner placement
If your website itself is slow to load, then as with large banners, users can sometimes “navigate away” from a page before the page has finished loading. In these cases, banners that are placed towards the bottom of the page may not get a chance to complete loading before the user goes elsewhere. Upgrading your server to ensure your web site loads quickly at all times will help, as may re-considering your website design and banner placement.
When OpenX version 2.6 was released, the OpenX ad server gained a new feature called Single Page Call. If you’ve got more than one banner on a page, then Single Page Call can be one way to get more performance out of your OpenX installation.
The way OpenX generally works is that for every position on your website that you want to display advertising, you set up what’s called a “zone” in OpenX. For every one of these zones, you then generate the zone’s “zone tag” (sometimes called an “invocation code tag”), and you put these tags into your page’s HTML source where you want the banners to display.
When your site is viewed, each zone tag in your site’s HTML makes a call off to your OpenX ad server, OpenX figures out what banner to show, and then sends it back, ready for display. So, if you have more than zone on a page, this means that you are going to be making more than one call to your OpenX ad server per page view.
The Single Page Call system, though, means that you can make just the one call off to your OpenX ad server to get all of the banners for the page, no matter how many zones you want to display. Fewer calls means less load on your ad server, and also means faster load times for your website.
You can find more information about generating the Single Page Call tag in the OpenX documentation. (The process in OpenX 2.7-beta is slightly different from that in OpenX 2.6, but unfortunately the OpenX 2.7-beta documentation doesn’t seem to be available from OpenX yet.)
However, what may not be immediately obvious from the OpenX documentation is that because OpenX’s Single Page Call code is generated at the website level, this means that the code will, by default, retrieve a banner for every zone configured in the website.
If you always display all of the zones on every page, then there’s no problem at all; but if you have many zones, and you don’t display every zone on every page, then using the Single Page Call code without modification will have two consequences.
Firstly, as you can probably imagine, the performance of your OpenX installation and your website will suffer. Asking OpenX to decide which banner to display for a given zone, and then having to transfer the banner display code for said banner, when you’re not even going to display it, is somewhat wasteful.
Secondly, if you have configured OpenX to log requests as well as impressions, you will notice that your requests are much higher than your impressions, because you are requesting banners that you then don’t even attempt to display. This often leads to concerns that perhaps there is something wrong with your OpenX installation, or that there is some reason why your impression values are “wrong” — when in fact, there’s nothing wrong at all, other than the fact you’re requesting banners that are never going to be used.
To improve performance, and to ensure that your request logging is correct, The Guru recommends that you use the “Advanced Usage” feature that is on the OpenX Single Page Call documentation. That is, if you are not going to display all of the zones defined for a website, and you are going to use the Single Page Call code, then you should define the OA_zones variable in JavaScript in the HTML header before your first Single Page Call code block, to limit the zones OpenX will request and return banners for.
For example, if your website has 5 zones defined (say they have zone ID values 1 through 5), and you are only going to display zone ID 1 and zone ID 4 on a page, then, you’d put the following code into your HTML header:
<script type='text/javascript'><!--// <![CDATA[
var OA_zones = {
'zone1' : 1,
'zone4' : 4
};
// ]]> --></script>
This code should be just above the “header script” part of the Single Page Call code, and of course, as per the OpenX documentation, you’ll need to change all of the “OA_show()” calls to match the names defined above — that is, when placing the “ad script” for zone ID 1 into your page, change the “OA_show(1)” to “OA_show(‘zone1′)”, and similarly for the “ad script” code for zone ID 4.
It may take a little bit of effort to implement, but the improved performance and more accurate statistics are well worth the effort.
|
Unofficial Hosted Issue List Ask The Guru Got an OpenX problem The Guru hasn't written a tip about yet? Got an idea for a tip? Email: theguru@openxtips.com.
|
[↩]