Key performance requirements

A Redgate Monitor installation has three components:

• A number of Base Monitors, responsible for sampling, managing and interpreting the sampled data.
• The repository, a SQL Server database that holds the sampled data and Redgate Monitor configuration settings.
• One Web Server, sitting between users and the data sampled by the Base Monitor.

Base Monitor capabilities

We recommend that each Base Monitor supports a maximum of 250 servers.

Requirements change with server load. For instance, monitoring 500 servers with a single instance requires fewer resources than monitoring 200 servers each running 100 instances with many concurrent connections.

Web Server requirements

The specification of the Web Server depends on how many people will access it and from where. We recommend allowing plenty of extra resources for expansion as you may add additional Base Monitors as your estate grows.

Perhaps most importantly: this does not, and cannot, take into consideration slow networks/WAN links. The speed of Redgate Monitor is limited by the communication time with the slowest Base Monitor. In cases where this is too slow, we recommend using another Web Server.

TLS requirements

Redgate Monitor uses TLS to communicate between the base monitor and the web server. By default, TLS 1.2 is used to communicate between the two components. If TLS 1.2 is not available, the Redgate Monitor will attempt to use TLS 1.1 to secure communication.

TLS 1.0 is no longer supported in Redgate Monitor as of version 10.0.9.

Disk requirements

Data repository

We recommend using low-latency SSDs for the Redgate Monitor data repository. 

The amount of disk space required also depends on your data retention policy. Setting short data retention windows will reduce disk space requirements. We do not recommend using the FULL recovery model. 

Base monitor and web server

There must be at least 500MB of free space for each of the components. We recommend having 1GB for each of the components to accommodate for the growth of application logs.

SQL Server for the repository

We recommend using SQL Server Enterprise Edition or SQL Server Standard Edition.

While it is possible to use SQL Server Express Edition, we recommend you set short data retention windows (1 week for data you want to view trends for, 3 days for troubleshooting data). In addition we recommend that customers using SQL Server Express Edition do not monitor more than 15 servers.

Example specifications for the Repository

10-20 servers

We recommend running the repository on a separate machine to the base monitor, with the following specs:

• Minimum 2 cores, 8GB ram
• Recommended 4 cores, 16GB ram

If this isn’t possible, so the repository is on a machine shared with the base monitor, guidelines for the shared machine are:

• Minimum 4 cores, 16GB ram
• Recommended 6 cores, 32GB ram

20-50 servers

We strongly recommend hosting the repository on a separate machine to the base monitor, dedicated to running this database. If the server must also service other workloads, revise these figures upwards accordingly.

• Minimum 4 cores, 16GB ram
• Recommended 8 cores, 32GB ram

100+ servers

We strongly recommend hosting the repository on a separate machine to the base monitor, dedicated to running this database. If the server must also service other workloads, revise these figures upwards accordingly.

• Minimum 6 cores, 32GB ram
• Recommended 12 cores, 64GB ram

Example specifications for the Base Monitor and Website

If you choose just the web interface, then this will be a 1- or 2-machine installation, with the Base Monitor and Web Server services running on the same machine, and the Redgate Monitor database also on the same machine, or remote. In larger estates, the overhead on a single server of running both services, plus reading and writing data to the repository, could affect the performance of the monitoring service. The recommended starter configuration is generally two separate servers, one to host the Base Monitor and Web Server, and one to host the Redgate Monitor database.

If you choose to install the Web Server and Base Monitor on separate machines, then it will be either a 2- or 3-machine installation, depending on the location of the Redgate Monitor database. If you plan to monitor more than 50 servers, then it is a good idea to install each of the three Redgate Monitor components (Base Monitor, Redgate Monitor Database and Web Server) on separate machines.

Scenario 1: 20–100 servers in one data center

For 20 servers or fewer, while in general we would recommend hosting the Web Server and Base Monitor on different host machines, adequate performance can often be achieved with one. 

For 50 servers, we recommend separate machines for the Web Server and Base Monitor:

For 100 servers:

Scenario 2: Multiple data centers

In this scenario we have 3 data centers connected via high performance fiber. We recommend locating the web server closest to the majority of Redgate Monitor users, in this case Site 1:

Scenario 3: One data center has more than 250 servers

In this scenario we use more than one Base Monitor for a single data center:

Scenario 4: Slow communication with one data center

In this scenario one data center has a slow communication link; we recommend two installations of Redgate Monitor:

Performance impact of monitoring

Redgate Monitor is designed to place low load on the servers that it monitors. It is hard to put a precise figure on this since it is determined by the level of the activity of the monitored SQL Server instance or instances on the machine. Typical values are around:

• 1-2% CPU utilization on a normal SQL Server or PostgreSQL instance
• For an Azure SQL Database, the normal load is approximately 1.5 DTUs and 2 workers consumed.
• For an Azure elastic pool, the normal load is approximately 1.5 DTUs and 2 workers consumed per database. Elastic pool's have relatively few workers, so it's important to check the official Elastic pool docs.
• 5-10 GB per server per day network traffic but could be significantly higher depending on the number of long queries or query plans generated.