This article applies as of PRTG 20

With a few hundred sensors, PRTG usually does not show any speed and performance issues. But with thousands of sensors, you might experience excessive CPU load, a slow PRTG web interface, or sensors that are not scanned at the specified intervals.

What can I do to make PRTG faster, use fewer system resources, and work more reliably?

• What aspects do I have to consider before the installation?
• What are best practices for large installations of PRTG?
• What can I do to enhance user experience, especially in the PRTG web interface?
• What can I do to speed up my installation?

How to speed up PRTG

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

1. Hardware
2. Operating System
3. PRTG Server Settings
4. Sensor Type and Monitoring
5. Housekeeping and Maintenance
6. More Resources and Facts

1. Hardware

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 for running a PRTG core server is 2 sockets with multiple CPU cores. For remote probes, it is 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).
In total, 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, which might result in performance issues within 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—prefer Intel

PRTG makes heavy use of multi-threading, so prefer systems with multiple cores. At least 4 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 OS: Install 4 GB of RAM. This will maximize the available RAM and disk cache.
• 64-bit OS: Install at least 4 GB of RAM, 8 GB is better and for more than 2,500 sensors strongly recommended.

Use a fast disk sub system

• Stick to simple RAID deployments like RAID 10 or RAID 1 for the 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. Measurements show 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 test figures on different hardware platforms and operating systems, see the "More Resources" section below.

2. Operating system

There are huge 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 at all costs

Both Vista and the first edition of Windows Server 2008 have serious performance issues, especially when you use WMI. Do not use them 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, 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 when you use other Windows versions! Our observation is that the effect increases with multi-core CPUs.

See also: Increasing the Performance of PRTG Core Server under Windows 2008

More

For detailed test figures on different hardware platforms and operating systems, see the "More Resources" section below.

3. PRTG server settings

You can win a lot by configuring your PRTG server smartly!

Use the latest PRTG version

We continually improve our software. To profit from all speed enhancements, please always run the latest PRTG version available for download. Use the PRTG Auto-Update to be sure 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.

Switch on the "speed" sption

This setting disables a few non-mission-critical features to speed up the web interface: From the PRTG main menu, choose Setup | System Administration | User Interface. In the Web Server settings, section Performance Strategy, choose the More Speed option.

For detailed information, see What does PRTG's "More Speed" option do?

Note: In previous PRTG versions, find this setting under Setup | System Administration | System & Website.

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 web server. If the internal 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 Web Server in the PRTG web interface.

Note: In previous PRTG versions, find this setting in the PRTG Server Administrator program (now: PRTG Administration Tool).

Testing the speed of your web browser

Note: To test the speed of your 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_OR_DNS**/speedtest.htm

4. Sensor type and monitoring

A solid monitoring configuration can considerably improve performance!

Use longer intervals

You can reduce monitoring load and data volume by 80% if you switch the monitoring interval of all your sensors from 1-minute to 5-minute intervals. Hint: Change the interval in the Root Group Settings and use the inheritance mechanism of PRTG to use this interval for all objects that are below in the object hierarchy.

Avoid frequent auto-discoveries

Depending on the configuration, an 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 discovery schedules to Once and run the auto-discovery manually when needed.

Use multiple probes

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

Prefer basic network sensor types

Basic monitoring sensors are simpler and therefore 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 high amounts of channels per sensor

Avoid a high amount 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, avoid v3

SNMP v3 does not scale well. SNMP v3 uses SSL encryption and creates a lot of CPU load. SNMP v1 does not support 64-Bit counters, which may result in invalid traffic data.

Avoid WMI whenever possible

Avoid WMI. WMI does not scale well. WMI uses DCOM to connect to other computers and has several Mutex/Semaphore issues that affect scaling.

Avoid network intensive and the more complex sensor types

Keep the usage of the following sensor types to a minimum: Sensor Factory, Packet Sniffers, VMware, Email Round Trip, SQL Server, CloudWatch, QoS, File, Folder, HTTP Full Page, and custom EXE sensors. Consider the color bar of a sensor type in the Add Sensor dialog that indicates the performance impact of a sensor.

Use NetFlow and sFlow instead of packet sniffing

For monitoring high bandwidth networks, NetFlow and sFlow are far more efficient than Packet Sniffing. For details, see 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

Especially for large installations, multiple user accounts and groups can slow down web server performance. In any case, stay under 20 user accounts for installations with more than 2,500 sensors.

Avoid defining many different access rights per node

Especially in large installations, this could slow down web server performance, depending on the depth of your object tree's hierarchy.

Avoid dependencies

In large installations, avoid configuring many different dependencies. In normal installations, dependencies will not be a problem.

Avoid schedules

Up to 20 schedules are no problem in any installation.

Avoid libraries

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

Avoid giant 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 Similar Sensors Detection

With the recommended default setting, PRTG automatically disables 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 analysis completely.

Turn off Recommended Sensors Detection

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 recommendation completely.

5. Exercise housekeeping

Do what every administrator should do.

Reboot regularly

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

You can schedule an automatic probe restart under Administrative Probe Settings in the PRTG web interface.

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

Defragment hard disks regularly

Monitoring software such as PRTG constantly writes data and logfiles on the disk. For large installations the constant flow of data to the disks can reach gigabytes per day. Although PRTG has built-in methods to minimize fragmentation, the data on your disk will fragment heavily because many large files are written simultaneously and incrementally throughout the day.

Run a defragger once per day: Enable automatic defragmentation (built-in for Windows Server 2008 and Windows 7), or install a defragger that can be run automatically every day or week.

Hint: We use the Freeware MyDefrag: To use the fast and easy program, create a scheduled task for OptimizeDaily.MyD or OptimizeWeekly.MyD.

Disable NTFS compression for monitoring database

By default, NTFS compression for the \Monitoring Database folder is disabled as of PRTG 12. We found that disabling compression actually increases performance for small to medium installations (less data needs reading, which leads to less fragmentation). For 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 program, switch to the Core Server tab and un-check the Use NTFS based file compression option next to the database path.

If you have enabled NTFS compression in an older version and now are running PRTG 12 or later, see the article 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

Disclaimer:
The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.