Kisai

Just to chime in. There are two ways to deal with this: A) use a script in the ad unit (make sure to clear the "This banner can be safely displayed inside an iframe (e.g. is not expandable)" otherwise it will not work. You can then use css media queries to resize the ad container (you will need to create a div around the <ins> tag used by the async code. You can NOT do this with iframes or the traditional document.write code) B) set the media queries in CSS to display:none the ad units that you do not want to render at that size. This actually does work, but will not work the way you expect it to if you're using header bidding (since header bidding will still make all the queries even if it's not rendered.) The preferred option is to just have an ahead-of-time script delete the <ins> units that won't be displayed before asyncjs is run, but if the client resizes the window, they won't come back, hence you can use the css queries to display:none them, but because asyncjs has already run, the ads will not change. I don't believe revive has a way of "refreshing" or "deferring" ad load like below googletag.cmd.push(function() { googletag.pubads().disableInitialLoad(); }); googletag.pubads().refresh(); For if it did, this would be easily solved by pausing the initial load, changing the ad units, then 'refresh' loading the ads. This would also make header bidding easier to manage.

Well it was fixed by something being replaced.

So I "might" have fixed this. I pulled https://github.com/revive-adserver/revive-adserver/blob/04ce3f2537b4209d1fc5b81aff3b51afb86c6dc4/etc/plugins/openXReports.zip from the versioning system and overwrote the files on my system. When the next time the stats ran, numbers started appearing. But I'm not 100% sure this was the fix, as I also applied https://github.com/revive-adserver/revive-adserver/commit/20d2526d48d6cb30af489809087b828e8b89954a to both systems as well as I had switched it to mysqli. It still bugs me that the stats stopped at all, so if either of these are responsible, I'd suggest rushing a 4.0.1 update.

Hello everyone. I updated two 3.2.4 installations to 4.0 on the 20th. Guess what is not working on both? On the older machine, all the stats have stopped dead, this one originally started out as OpenX Source 2.8 . Doing select * from ox_data_bkt_m; Results in data... from 2013. Clicking on the statistics in the Revive UI results in no statistics whatsoever since the upgrade. On the newer machine SELECT * FROM data_bkt_m; Has data from today. However it's data is very very wrong, like 99% of the statistics are missing. Some campaigns that normally have 2 million impressions on remnant have zero or just 10,000, while other campaigns that normally have 100,000 or so also have like 12,000, which there is no way the little site would have more impressions than the large site. I know the ads are still being delivered because the ad partners show the correct values for requests handed off to them. The debug log on both servers show that stats are running, both are running on crontab. Both servers had php updated to PHP 5.6.28 with Zend OPcache at the same time. So this makes me question: 1) Is there not a reference table schema that I can use to check if the database tables are correct? 2) what would make one server produce no stats, while the second server produce only a few? This suggests that some migration element failed. What changed between 3.2.4 and 4.0 that would do this?

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.