firstimpression

Morning/Afternoon All,
I'm sure that you are allaware of the changes to how cross-site cookies are going to be handled by browsers.  Please see - https://blog.chromium.org/2019/10/developers-get-ready-for-new.html  For anyone serving ads to Ad Exchanges and/or Networks this is going to be an issue.  Are there any plans to roll out a solution?  Or am I missing a solution that already exists (my programming skills are somewhat rusty)?  Any assistance in the matter would be appreciated.
Cheers,
KirkM   

@kanuns, this is totally possible.
If you set up MySQL replication you can replicate your set up whenever MySQL slaves will be able to connect to master.
If you know IP addresses of your remote servers then you can run maintenance-distributed to pull statistics to master server.
With this scheme you will have all the stats on the master server. To have all the rest of the stuff synchronized you will have to write a few scripts that will put graphic assets to your remote servers. 
 

Had exactly the same problem.
In the end the problem was that if you supply an HTML banner, and the zone is rendered under SSL, Revive performs a check if there is any SSL-unsafe code in the banner. If it does detect that kind of code, the the banner is simply not delivered.
In my case, I have added banner with the following type of code: <iframe src=http://...></iframe>
The snippet that loaded from SSL URL of Revive did not serve that banner, while non-SSL version of snippet did.

You can also try enabling gzipping on your webserver, this will save about 50% of HTML/JS (although, it will not compress your images any more).
If you have multiple zones, then try to implement single page call, this will significantly save overhead bandwidth of querying code per each zone.

According to this webserver config, any request like mydomain.com/images/image.jpeg would be fetched from /opt/revive-adserver-4.0.1/www/images/image.jpeg.
You have to configure your webserver accordingly if you want to serve over HTTP anything that is outside of www folder. You can use Alias or RewriteRule directives.
 

@Accuraty, from my experience, after you run out of disk space, and after you solve the issue by freeing up some space, you have to restart MySQL. Otherwise it just continues to behave as if there is still no space available.

This is very problematic.
I'd suggest you to put a symlink named "www" that would point to "public".

As a temp walkaround: if you use nginx as frontend you can add headers in nginx host config.

Thank you for your reply. In the end it was something that I edited in Revive's core code.
Just wanted to confirm that it was an incorrect behavior.

Solved this by compiling PHP's pecl mysql extension from source:
$ git clone https://github.com/php/pecl-database-mysql mysql --recursiveGo to directory of the downloaded files, and then:
$ phpize $ ./configure $ make $ make installThen you have to register the extension in php.ini:
extension=/usr/local/lib/php/[. . . path to PHP extensions]/mysql.soThen restart Apache, and Revive works fine.
PS. When I ran "configure" I also had to specify path to php_config:
./configure --with-php-config=/usr/local/bin/php-config
 
 

var/*.conf.php

In php.ini edit the line "date.timezone=..." and set it to:
date.timezone = UTC 

Your hosting provider is absolutely correct, although, this is a very wide question, and you did not even provide any details on the system that serves 1M impressions.
You should find bottlenecks - analyze CPU load, system load, memory availability, etc. You should also check limitations that you have set on your web server (max processes, and such) by monitoring your server with different tools.
I am sure you haven't exploited yet the optimization boost that can give you memcached, mysql query cache, xcache, eAccelerator, nginx, and a whole bunch of other approaches that you can easily find on the internet.
 
If the number of campaigns, zones, banners, etc, is low, then it should be enough 2 CPUs/4GB RAM with proper system settings to serve 1M daily.
 
Either way, what you describe sounds like Apache is thrashing as it reaches ServerLimit, try checking that.