This article applies as of PRTG 22

How to speed up PRTG

To speed up your PRTG core server system, consider the following topics:

1. Hardware
2. Operating system
3. PRTG core server settings
4. Sensor type and monitoring
5. Do regular cleanups
6. More

1. Hardware

Important: Choose performant hardware.

Physical and virtual servers

In general, we recommend that you use a dedicated physical machine to run both the PRTG core server and remote probes. The best configuration to run a PRTG core server is two sockets with multiple CPU cores. For remote probes, we recommend a single socket with multiple CPU cores.

If your PRTG core server or remote probe is running on a virtual machine (VM), make sure that you configure the VM with a multi-core-per-socket configuration. By default, your hypervisor might configure the VM the other way around (multiple virtual CPU sockets, each with one core).

Both approaches result in the same number of virtual CPU cores. However, the multi-core-per-socket configuration increases the CPU performance compared to the multi-socket single-core configuration. This might cause performance issues with the VM.

Running large installations of PRTG in a virtual environment is possible if you follow some specific rules and guidelines to achieve the required level of performance. For more information, see our Best Practice Guide: Running large installations of PRTG in a virtual environment.

Use multi-core, multi-threaded CPUs, and/or multi-processor systems

PRTG makes heavy use of multi-threading, so prefer systems with multiple cores. At least four cores are mandatory. In our tests, Intel processors outperformed AMD CPUs.

Install more RAM

More available memory can significantly improve the speed of PRTG.

• 32-bit operating system: Install 4 GB of RAM. This maximizes the available RAM and disk cache.
• 64-bit operating system: Install at least 4 GB of RAM. 8 GB is even better. For more than 2,500 sensors, we strongly recommend that you install 8 GB of RAM.

Use a fast disk subsystem

• Stick to simple RAID deployments like RAID 10 or RAID 1 for best performance with any controller or setup.
• As a rule of thumb, higher RPM disks are always faster than lower RPM disks.
• Avoid storage that adds a lot of overhead (iSCSI or SMB shared folder or drive) to disk access.
• Use SSDs. Tests have shown that using an SSD in a PRTG server can decrease page load times by 25-35% compared to a normal disk. Even faster are M.2 SSDs with NVMe.

More

For detailed figures of tests on different hardware platforms and operating systems, see section More below.

2. Operating system

There are big differences between the various Windows versions.

64-bit Windows version is better than 32-bit

According to our tests, 64-bit operating systems have a somewhat higher performance compared to 32-bit systems.

Select the fastest operating system available to you

The best operating systems for PRTG are, in order of performance:

1. Windows Server 2012 R2
2. Windows Server 2016 and Windows Server 2019
3. Windows 10 and Windows 8.1
4. Windows Server 2008 R2
5. Windows 7

Avoid Windows Vista and Windows 2008 R1

Both Windows Vista and the first edition of Windows Server 2008 have serious performance issues, particularly if you use WMI. We strongly recommend that you do not use these operating systems for large installations.

Note: Windows Vista is not officially supported anymore. See Windows Vista support has ended for more information.

Avoid the Balanced power plan on Windows Server 2008

On Windows Server 2008, the power plan Balanced is the default setting. Switching to the High Performance power plan can lower your average web page load times by 30-50%, even if you use other Windows versions. We have observed that the effect increases with multi-core CPUs.

See also: Why is the performance of my PRTG Core Server so low under Windows 2008?

More

For detailed figures of tests on different hardware platforms and operating systems, see section More below.

3. PRTG core server settings

You can increase performance with a smart configuration of your PRTG core server.

Use the latest PRTG version

We continuously improve our software. To benefit from all speed improvements, always run the latest PRTG version that is available for download. Use the auto-update functionality of PRTG to make sure that you always run the latest version.

Configure memory usage

Check the memory usage of your PRTG Server process. For values above 1 GB, navigate to Setup | System Administration | User Interface in the PRTG web interface, section Graph Settings, to reduce RAM usage. Choose the smallest settings that still make sense for your use case. The objective is to avoid slow memory swapping at all costs.

Note: In previous PRTG versions, define this setting in the PRTG Server Administrator tool, tab Memory usage.

Use the setting to limit features

This setting disables a few non-mission-critical features to speed up the PRTG web interface: Select Setup | System Administration | User Interface from the main menu. In the PRTG Web Server section, select Limit features and delay display under Performance Handling.

Switch the PRTG web server from HTTPS to HTTP

If you can afford a lower security level (for example, if your PRTG web server is not publicly accessible), you can disable HTTPS for the PRTG web server. If the PRTG web server is not encrypted, it delivers web pages faster and does not have to handle that much workload. Change this setting under Setup | System Administration | User Interface, section PRTG Web Server in the PRTG web interface.

Note: In previous PRTG versions, you can find this setting in the PRTG Server Administrator tool.

Test the speed of your browser

To test the speed of the PRTG web interface and measure the success of any optimization efforts, log in to the PRTG web interface and manually call the /speedtest.htm URL in your browser, for example: http(s)://<your-prtg-ip-address-or-dns-name>/speedtest.htm

4. Sensor type and monitoring

A solid monitoring configuration can considerably improve performance.

Use longer scanning intervals

You can reduce monitoring load and data volume by 80% if you switch the scanning interval of all your sensors from 1-minute to 5-minute intervals. The best way to do this is to change the scanning interval in the root group settings and use the inheritance mechanism of PRTG to use this scanning interval for all objects that are underneath in the object hierarchy.

Avoid frequent auto-discoveries

Depending on your configuration, the auto-discovery can scan your entire network and therefore produce a certain amount of load. Minimize the number of scheduled auto-discoveries whenever possible. We recommend that you do not schedule an auto-discovery to run every hour. If possible, set the auto-discovery schedules to Once and run the auto-discovery manually when necessary.

Use multiple remote probes

Distributing the monitoring load among several remote probes is always a good idea to relieve your system.

Prefer basic sensor types

Basic sensors produce little header traffic or system load. They use fewer system resources than the more advanced technologies:

• SNMP
• PING
• HTTP
• SMTP
• Port
• DNS
• FTP
• POP3

Avoid a high number of channels per sensor

Avoid a high number of channels per sensor. Note that sensors with more than 50 channels are not officially supported and can have a high impact on system performance.

Use SNMP v2c and avoid SNMP v3

SNMP v3 does not scale well. SNMP v3 uses SSL encryption and creates a lot of CPU load. SNMP v1, on the other hand, does not support 64-bit counters. This can result in invalid traffic data.

Avoid WMI if possible

Avoid WMI because it does not scale well. WMI uses DCOM to connect to other systems and has several mutex/semaphore issues that affect scaling.

Avoid network-intensive and more complex sensor types

Keep the usage of sensors with a high or very high performance impact to a minimum. For more information, see the PRTG Manual: List of Available Sensor Types.

Use NetFlow and sFlow instead of packet sniffing

For monitoring high-bandwidth networks, NetFlow and sFlow are far more efficient than packet sniffing. For more information, see the PRTG Manual: Bandwidth Monitoring Comparison.

Minimize the use of NetFlow and sFlow sensors

Depending on the traffic pattern, using NetFlow or sFlow can create a lot of CPU load and data.

Avoid Toplists

Keep the usage of Toplists to a minimum. Depending on the traffic pattern and Toplist configuration, this feature can create a lot of CPU load and data.

Avoid multiple user accounts and user groups

In large installations, multiple user accounts and user groups can slow down the PRTG web server performance. We recommend that you stay below 20 user accounts for installations with more than 2,500 sensors.

Avoid defining many different access rights per object

In large installations, this could slow down the PRTG web server performance, depending on the depth of the object hierarchy in your device tree.

Avoid the use of dependencies

In large installations, avoid configuring many different dependencies. In normal installations, dependencies do usually not cause any issues.

Manage the use of schedules

Up to 20 schedules are fine in any installation.

Manage the use of libraries

Remove all (default) libraries that you do not need.

Avoid huge reports

Reports can considerably slow down the system. Create only the smallest reports possible, avoid reports with many sensors over long periods, and run reports during times when nobody or few people use the PRTG web interface.

Turn off the Similar Sensors Detection feature

With the recommended default setting, PRTG automatically disables the similar sensors detection if your installation exceeds 1,000 sensors. If you want to keep the system load of PRTG to a minimum even for smaller installations, turn off the similar sensors detection completely.

Turn off the Recommended Sensors Detection feature

With the recommended default setting, PRTG automatically disables the detection engine if your installation exceeds 5,000 sensors. If you want to keep the system load of PRTG to a minimum even for smaller installations, turn off the recommended sensors detection completely.

5. Do regular cleanups

Keep an eye on your PRTG core server system and setup.

Restart regularly

We found that, in the long run, servers run more reliably when they are restarted once a month. Consider automatic restarts as often as once per week for systems that run heavily-used remote probes, too.

You can schedule an automatic remote probe restart in the probe settings in the PRTG web interface, section Administrative Probe Settings.

Note: In previous PRTG versions, set automatic Restart Options in the Probe Administrator tool, tab Start/Stop.

Regularly defragment hard disks drives (HDD)

PRTG constantly stores data and log files on the disk. For large installations, the constant flow of data to the disk can amount to many gigabytes per day. Although PRTG has built-in methods to minimize disk fragmentation, the data on your disk heavily fragments because many large files are simultaneously and incrementally stored throughout the day.

If you use HDDs, we recommend that you do a defragmentation once per day. This is not necessary if you use SSDs.

Disable NTFS compression

By default, NTFS compression for the \Monitoring Database subfolder of the PRTG data directory is disabled as of PRTG 12. We found that disabling compression actually increases performance for small to medium installations because less data needs reading. This leads to less fragmentation. In large installations, this can have the opposite effect.

To disable compression in (deprecated) versions before PRTG 12, where it was automatically enabled during installation, open the PRTG Server Administrator tool, go to the Core Server tab and disable the check box next to Use NTFS based file compression.

If you have enabled NTFS compression in an older version and are now running PRTG 12 or later, see How can I disable/enable NTFS compression for PRTG's local data storage?.

Note: Do not convert already compressed data to uncompressed data. This process causes heavy fragmentation.

More

• Planning large installations of PRTG Network Monitor