After explaining this so many times to on-boarding Broadstreet users, we thought it’d be a good idea to put it down in writing once and for all. This is why the wheels fall off the average open-source instance of OpenX as a site grows its page traffic.
This is a technical post, but we’ll keep it high-level enough that most non-technical readers can follow along. It’s a lesson in Dev-Ops for the average person.
If you don’t care to read the details below, just know that Broadstreet’s team is really good at saving people from OpenX. We can help you too. Sometimes we can do it for free. Contact us if you need help.
If you’re not sure whether your OpenX is running on LAMP, it probably is.
LAMP stands for Linux, Apache, MySQL, PHP. They are four separate pieces of software that do different things needed to build a web application:
So let’s talk about why LAMP isn’t the best choice when building and running and adserver.
It’s not that PHP is a terribly slow language. Platforms like WordPress, Drupal, Joomla, and thousands of others run on PHP. Much of Yahoo and Facebook is running on PHP. But for serving ads, you really have a different set of needs from the language you’re building your ad engine in.
PHP is a scripting language. In a default setup, every time a PHP script is run (like during an ad call), the PHP interpreter has to open up the PHP file, and parse and execute the PHP code inside. And chances are, that same file is including a lot of other PHP files which invoke the same process.
In most cases, every single ad call invokes the parsing process over again.
Other languages, like C, compile to machine code and don’t require any sort of interpretation or run-time parsing. C is great for writing adservers, but not PHP.
Apache is the world’s most popular web server. It takes requests from users’ browsers, feeds the request to PHP via a loaded module, gets the output, and sends it back to the user.
When it comes to serving static images like ads, it tends to become a major bottleneck because new Apache processes with large memory footprints are loaded all to simply open a file and send the data back.
To top it off, constantly reading data from disk isn’t very performant in itself. Disk access can be largest bottleneck in a web application.
The bottom line is that while Apache can serve big static files, it shouldn’t since it isn’t specialized for the task.
We said that MySQL is the database where information about ads, advertisers, and your site data is kept. It also stores statistics like impressions and clicks.
While MySQL is a hella-sturdy and tested database, tracking impressions and clicks can be extremely stressful on it. Every time a user loads an ad, which may be 20-30 times on a page (the case for many local news sites with a lot of ads), MySQL is being sent at least 20-30 new rows of data. Every so often that data is crunched down and and archived in OpenX’s stats table, which tends to grow extremely large.
After a building a successful news website and running OpenX for a couple years, you’re guaranteed that reporting functions and basic adserving will be infuriatingly non-performant.
It would actually be a better idea to do it right from the start, and jump on a cloud hosted platform like Broadstreet.
There are plenty of things you could do to give OpenX a boost. You could solve the Apache filesystem problem by using an HTTP accelerator like Varnish. You could solve the PHP problem by installing an Opcode Cache like APC or xcache. You could solve the MySQL problem by using a better database engine like Percona.
But chances are, a news publisher isn’t going to do that, because they don’t know how, and finding and hiring a developer who will do it can be pretty expensive.
At the point where OpenX is creating these sort of problems, you should ask yourself: “Should I just move my ads to the cloud?”
Yes, you should. And luckily, Broadstreet provides low-cost adserving that is many times better than OpenX ever was and will ever be. And you should contact us too! We’ll get your data off OpenX and import it into Broadstreet.
OpenX was great when it first came out, because it brought smart ad management to the moderately savvy developer and publisher. It was written in PHP to facilitate widescale usage. Most developers would be able to easily run it − after all, PHP and Apache were and still are the most popular platforms to build a web application.
It was a choice of portability, which worked out well, until some of the more successful users started having inevitable speed issues. That’s also why OpenX launched its enterprise product for those with deep pockets.
OpenX is great for starting out, but it creates more headaches down the road, especially if your site is successful. The best route is to avoid using it entirely. The next best route is to find a good company that can help aboard something a little more scalable.
Stay up to date with the latest marketing, sales, and service tips and news.