Mobile advertising is a fast moving industry. Driven to new levels by the growth of programmatic, performance and advertising tech, advertisers now serve thousands of adverts every second of every day to users across the world.
But Supply Side Platforms (SSPs) can face problems as they grow. As new publishers join a platform, the service is expected to deliver the same quality while scaling to a larger publisher base.
This is a problem that PubNative is familiar with. The arrival of new clients who, in some cases, significantly increased the workload of our server caused some performance issues. But, after some careful troubleshooting of the PubNative technology, we realised that a process called Garbage Collection (GC for short) was causing a bottleneck and slowing our service down.
As a result, we’ve created a MySQL driver for the Go language that hasn’t just solved the problem we’ve had; it’s increased the performance of our GC three times over, in turn increasing ad server performance. So we thought we’d explain what the problem was, how we fixed it and where you can download our solution for free.
While most of you reading this will be familiar with GC, it’s worth having a quick rundown of the process and its inherent issues, in order to understand why we focused our attentions there.
GC works by freeing up unused memory space within an application. By working out which objects are live and which aren’t, it attempts to reclaim memory occupied by those objects that are no longer in use (known as garbage). As a result, it improves the management of memory within an app and prevents factors like memory leaks to ensure it runs smoothly.
There is, however, a tradeoff that needs to be made. To determine those objects that need to be live, GC requires a brief ‘pause’ in the application to allow for it to turn off the object (AKA collect the trash). However the longer the pause is, the more it impacts on performance.
Simplicity Over Complexity
The trick, therefore, is to reduce the amount of trash that a GC needs to collect to prevent the pause from becoming too long. And that’s where we come in.
We began troubleshooting and discovered that one of the major causes was the MySQL driver running the GC.
Examining the driver, we found that the generic MySQL scan method we were using was storing too many objects in the heap, classifying too many objects as trash and lengthening the pause. We therefore wanted to create our own library with a higher throughput and better response time, cutting the number of instances and machines to do so.
We decided to write our own driver in an attempt to solve the problem. Prioritising the issues outlined and committing ourselves to the principle of simplicity over complexity, we created a GC “friendly” driver. This reduced the number of objects stored in the heap by using Go’s escape analysis to instead allocate these to a stack.
As a direct result of using this driver, we’ve been able to reduce GC threefold, significantly reduce the length of the pause time, and achieve our goals by improving the serving of our adverts to our expanded publisher base.
We believe that there are clear benefits to using the driver we have created and so made it available for you to use for free.
We can’t say for certain that you’ll see the same results as us. But as the driver has offered us clear benefits, we thought it should be made available for the open source community who may have similar concerns. You may even find a way to improve the driver further, and we’d be happy to hear it.
You can examine the driver and the documentation on GitHub, and we encourage you to use it. It’s helped tackle our GC performance problems and we hope it can help you to solve yours as well.BACK