Page Comparison

...

• If the Revive Adserver installation is sharing a server with other services, consider if the other services can be moved to another server, to give Revive Adserver a greater share of the server's CPU capacity.
• If the Revive Adserver database is on the same server as Revive Adserver itself, consider if the database can be moved to another server, to split the CPU used for Revive Adserver from the CPU used for the database.
• If you are using SQL Local Banners and/or Webserver Local Banners stored in a local directory, consider if these could be migrated to be delivered from an external host - doing so could significantly reduce the CPU use associated with banner delivery. (Alternatively, the use of a CDN service to cache the banners could help.)
• Consider if running a PHP OPCode cache, which will cache a "compiled" version of the code, to save on CPU time when running the scripts, is appropriate.

...

• If the Revive Adserver installation is sharing a server with other services, consider if the other services can be moved to another server, to give Revive Adserver a greater share of the server's memory capacity.
• If the Revive Adserver database is on the same server as Revive Adserver itself, consider if the database can be moved to another server, to split the memory used for Revive Adserver from the memory used for the database.
• If you are using SQL Local Banners and/or Webserver Local Banners stored in a local directory, consider if these could be migrated to be delivered from an external host - doing so could significantly reduce the memory use associated with banner delivery. (Alternatively, the use of a CDN service to cache the banners could help.)

Otherwise, you may need to consider upgrading your server to add more memory capacity.

...

• If the Revive Adserver installation is sharing a server with other services, consider if the other services can be moved to another server, to give Revive Adserver a greater share of the server's disk I/O capabilities.
• If the Revive Adserver database is on the same server as Revive Adserver itself, consider if the database can be moved to another server, to split the disk I/O for Revive Adserver from the disk I/O for the database.
• If you are using SQL Local Banners and/or Webserver Local Banners stored in a local directory, consider if these could be migrated to be delivered from an external host - doing so could significantly reduce the disk I/O associated with banner delivery. (Alternatively, the use of a CDN service to cache the banners could help.)
• Consider if the Banner Delivery Cache settings are appropriately set - a higher cache time will mean fewer disk I/O accesses to retrieve banner details from the database.
  • Please also note that different cache mechanisms (e.g. file-based vs. memcache-based) may deliver different levels of performance, and those levels may not necessarily be as you would intuitively expect.
  • Consider testing the performance differences with the different supported caching mechanisms, to see which works best for you.
• Consider if the Banner Logging settings are appropriate - in particular, note that logging requests as well as impressions effectively doubles the number of records recorded for each banner delivered, compared with just recording impressions.

Otherwise, you may need to consider upgrading your server to add more disk I/O capacity.

Database Performance

If you have carried out the above steps with regards to reviewing performance data, and already moved to a multi-server approach, with a separate database server, and you continue to have performance issues with the database server, consider if the following may help:

• Review the appropriate documentation for your database type.
• Consider if, based on your experience with managing the different types of supported databases, using MySQL vs. PostgreSQL is the correct database choice for your needs.