Managing Performance

 

On This Page:

Managing the performance of Revive Adserver.

There are a number of things that you can look at in terms of managing the performance of a Revive Adserver installation.

 


Upgrade Revive Adserver

If you are not running the latest major release of Revive Adserver, then you may well be missing out on performance improvements that have been released. Consider upgrading your Revive Adserver installation, which is also a good security practice.

Upgrade PHP

If you are not running the latest version of PHP supported by Revive Adserver, then you may well be missing out on performance improvements that have been released. Consider upgrading your PHP installation, which is also a good security practice.

Review Server Performance Data

If you want to manage the performance of a Revive Adserver installation, then having access to server performance data is essential. Without it, it is impossible to make effective changes to your setup.

In particular, you must have access to graphs that show you:

  • CPU Utilization
  • Memory Utilization / Swap Space Use
  • Disk I/O Performance

The following advice is based on having this information.

High CPU Utilization

In the event that your Revive Adserver installation is on a server that is suffering from high CPU utilization, consider if the following may help:

  • 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.

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

High Memory Utilization

In the event that your Revive Adserver installation is on a server that is suffering from high memory utilization, consider if the following may help:

  • 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.

High Disk I/O

In the event that your Revive Adserver installation is on a server that is suffering from high disk I/O, consider if the following may help:

  • 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.