Server requirements 80M impressions

[frifri]

Hi all,

We are looking to use Revive.

Could you please help me on the server requirements?

We should be able to serve 80M impressions monthly. Do you need more info?

What is your recommendation regarding the server? 

 

Thanks in advance for your help.

[Richard Foley]

This fellow is running at 382 million / month, perhaps this thread can help you? http://forum.revive-adserver.com/topic/3070-performance-questions/#comment-6556

[Ian]

It all depends on your server setup as well (e.g. want to build in high availability?)
80MM/month should be already possible on a 'bigger' VPS.

[frifri]

On 1/21/2016 at 2:53 PM, Richard Foley said:

This fellow is running at 382 million / month, perhaps this thread can help you? http://forum.revive-adserver.com/topic/3070-performance-questions/#comment-6556

Yes but in my case with 80 million / month, isn't a too big server configuration? 

We guess using a dedicated single server for this. Note that we will hosting our own banners.  

Also, we have a peak between 11:00AM and 12:00PM where we will have nearly 60 banners impressions/calls per second.

 

 

What do you mean by "want to build in high availability"?

 

Thank you

[Ian]

I mean by high-availability that if the server breaks down that another one takes over.

 

80 Million/imps a month can be ran on a 4GB memory, 2vCPU VPS if you are able to config it right.

[Gonzalo]

I mean by high-availability that if the server breaks down that another one takes over.

 

80 Million/imps a month can be ran on a 4GB memory, 2vCPU VPS if you are able to config it right.

Hi Ian,

 

Thanks for your insight here. I have a question, when you say 4gb + 2vCPUs will be able to handle 80mm/month impressions... are you talking about a PHP server + Apache + MySQL all in just one VPS?

 

Thanks

[Ian]

Yes, it is possible if you also use php-fpm with opcode caching, and enable Memcache within Revive.

[Kisai]

A properly configured machine uses php-fpm, with the opcode cache. The webserver itself is not relevant (it's only relevant to non-CGI php parsers, eg mod_php on apache) though we use nginx. The most important factor is RAM, you do not want the swapfile to be touched, and should set linux swapiness to 0. Web servers should always have swapiness set to zero, otherwise a load spike or DDoS magnifies the downtime. Better to temporarily deny access to a few than to give everyone who links to the ad server a bad experience.

Our small machine does at least 5 million (eg 60 million per month) impressions per day, our large machine does more than 15 million per day (eg 450million per month.). The small machine is a VPS (2vCPU/8GB ram,) the large machine is a non-VPS 4core/16GB ram machine. The machines are independent. It's very likely that we could run all of this from one machine but the zone counts below suggest otherwise (there are 150 sites with at least 3 zones each, total zones around 450.) 

There are however scale issues:

The small machine before being upgraded from openx to revive used to time out frequently due to too many zones and this was solved by adding an index at the database level. It's since been upgraded to Revive and doesn't experience that problem anymore.

Both machines experience "too many banners" or "too many zones" types of issues, where you can keep adding banners or zones, but if you try to copy a campaign with too many banners, it will timeout. The server will let you add as many banners as you want, but it won't let you delete them if the campaign is too large. Likewise the "select all" always fails in selecting zones to link for a campaign. 

Async (asyncjs.php) is used for the majority of the sites on the large server, this is the recommended solution as it creates an iframe and doesn't block loading of a page, and if the ad server is interrupted, it doesn't make the user experience any worse. the SPCJS (single call javascript) is actually worse than iframes due to document.write causing document reflows, and if the ad server is interrupted the entire site is unusable until the client times out.

Adblockers fail to block asyncjs.php, but they do tend to generic-block other parts of the script and css names used by advertisements.

 

Overall, adding more sites/zones and banners is not a problem. It's trying to do anything that involves bulk-changes. When you use the statistics it also can timeout. 

 

 

[Ian]

Sure, there are even more things to tweak, like the TCP stack and such. The timeout with running statistics can be solved by adding a MySQL slave, and run reports there :)