Simon Willison’s recent post about “Wait For It” made me think about performance in the ad-serving sphere.
If you’re a publisher with a single web server running your web site and an Openads installation, you’re probably not too worried about performance. So long as your website displays quickly, that’s about all that matters. However, if you’re lucky, your website is getting bigger, and you’re starting to worry about performance.
Alternatively, if you’re using Openads to display ads on other people’s web sites, you’re already worried about performance - the publishers that you serve ads to get pretty irate when their web site “hangs” for 10 seconds every time it gets to a location where an ad needs to go.
So, here are my top five tips for making sure that your Openads site performs as well as it can:
Monitoring
You simply have to have good monitoring of your server(s). Occasionally logging in and looking at top is not enough. You need to know what the CPU utilisation is, what the load is, how much RAM is in use, how much disk IO there is, and how often you’re swapping RAM to disk, all the time. If you don’t have this information, you won’t know where your system bottlenecks are, and you won’t know how to beef up your systems to cope with growth. You probably won’t even know that you need to improve your capacity until it’s too late, and everything has come to a grinding halt.
So, start monitoring now! Check out Cricket, Nagios, or OpenNMS.
PHP Cache
Use a PHP Cache. Easy to do, great for you CPU utilisation!
Manage Disk I/O
Openads is different to just about every open source PHP application. Mostly, PHP-based software is about a database driven web site. Openads delivers content to web sites, for sure, but most of the real load comes from logging all those impressions and clicks. This means you have to sort out your disk I/O - you’ve got a lot of data to write.
So, if you’re expanding your Openads capacity, think about getting a separate, stand alone database server. Make sure this server has great write capacity - wherever possible, go for the fastest drives you can afford, and remember that the more drives you have in a RAID 0 or RAD 10 configuration, the better - writes are faster when you can stripe them across more spindles.
Finally, remember that RAID 5 is a really, really bad idea!
Move Creatives Off-Server
You might also be able to improve your performance per cost ratio by serving up your banner creatives (assuming you’re not serving up text ads, or ads where the creatives come from a 3rd party) from a separate server, or even a cluster of servers. Openads supports configuring your system to load your creatives onto an FTP server, where they can then be distributed by a web server (or cluster) configured specifically for high-speed file delivery, or, if you really need the performance, by a Content Delivery Network.
Use Caching
Openads 2.0 has a number of different options for delivery engine caching, each with various pros and cons. However, to make it simple: The easiest and simplest to use is “file” based caching. Unless you have a reason to use anything else, use that!

Tags:
we run a dedicated Openads db with 3 load balanced php servers handling delivery, and have noticed just how intensive the db writes are.
we’re at about 20 writes a second on average (peaking at around 40 writes a second), and are looking to scale this out further and considering other ways to keep the stats.
one implementation that occurred to me is to write the raw stats to a syslog facility instead of the db, and have the processing scripts run over these logs to produce statistics,
would the Openads team be interested in patches to implement such a feature?
Comment by justin — June 12, 2007 @ 1:03 am
Writing to a syslog facility is an interesting idea, and one that we have considered for Openads. The reason we haven’t implemented it ourselves is that Openads 2.3 supports conversion tracking, and to do that effectively, a syslog of the raw data won’t do the job.
Instead, for really large setups where a single core database isn’t fast enough, Openads has support for “distributed statistics” - where every web server in your cluster runs a slave database (a partial replication of a core database). Each web server then logs its own statistics to the local database, and performs a partial statistics summary locally. This data is then pushed to the core database, where the remaining statistics generation that requires a complete view of the raw data can be performed.
Comment by Andrew Hill — June 12, 2007 @ 6:26 am
Andrew,
Is there any documentation that explains the “distributed statistics” deployment option?
David
Comment by David — July 19, 2007 @ 2:34 am
Hi David.
You can find the documentation for installing distributed stats.
https://developer.openads.org/wiki/DistributedStats
You will need time to implement this …but believe me this works best for high volume serving.
Comment by Mayavi — September 25, 2007 @ 8:44 am
[...] OpenAds Performance Tuning. Great article on Performance Tuning of OpenAds. [...]
Pingback by OpenAds performance tuning at btard deleted nostatus — January 16, 2008 @ 8:43 am