New Question
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

300.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Download >>


What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more


Top Tags

View all Tags

How can I speed up PRTG—especially for large installations?



Your Vote:



With a few hundred sensors, PRTG usually does not show any speed and performance problems. 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?

hardware important installation make-faster planning prtg sensor-type server-settings speed troubleshooting

Created on Mar 19, 2010 12:24:20 PM by  Daniel Zobel [Product Manager]

Last change on Aug 24, 2020 5:21:46 AM by  Maike Guba [Paessler Support]

13 Replies

Accepted Answer



Your Vote:



This article applies as of PRTG 20

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 2 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.
  • As a bonus, you can use SSD disks. We have not yet extensively tested this, but early measurements show that using an SSD disk in a PRTG server can decrease page load times by 25-35% compared to a normal disk.


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


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.

Graph Settings in PRTG System Administration
Click to enlarge.

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:


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


Created on Mar 19, 2010 1:40:54 PM by  Dirk Paessler [Founder Paessler AG] (10,932) 3 4

Last change on Dec 3, 2020 10:49:41 AM by  Brandy Greger [Paessler Support]



Your Vote:



Created on Apr 6, 2010 7:50:43 AM by  Jens Rupp [Paessler Support]

Last change on Apr 12, 2010 8:22:52 AM by  Daniel Zobel [Product Manager]



Your Vote:



In your article above, you mentioned...

"Keep usage of the following sensors to a minimum: Sensor Factory, Packet Sniffers, VMware, Email Round Trip, SQL Server, Cloudwatch, QoS, File, Folder, HTTP Full Page, Custom EXE Sensors"

We have a fairly large installation of PRTG with over 7,000 sensors. We have quite a few of the above mentioned sensors. It would be helpful to have more solid guidelines on usage of these sensors rather than simply to keep them at a minimum. How many is too many? Can you give us a number or a percentage?

Created on Nov 1, 2010 2:50:34 PM by  Scott K (60) 1 1



Your Vote:



@Scott K: The sensor types mentioned for "keep to a minimum" are either creating considerable more CPU or considerable more network load so we recommend to avoid using them too often (more than 10-100 sensors per type) in large installations.

On the other hand especially PING and SNMP sensors are creating the smallest footprint of all sensor types, followed by the Internet standard protocols like HTTP, SMTP, POP3, IMAP. WMI uses a lot more cpu cycles, etc.

What we want to say with "keep to a minimum": If you can perform monitoring for specific devices with the less cpu intensive sensors you should do so.

Note: Most of these considerations only come into perspective if you hit any resource limits in the first place.

Created on Nov 2, 2010 7:31:10 AM by  Dirk Paessler [Founder Paessler AG] (10,932) 3 4



Your Vote:



Another solution for Defrag which is Free for Commercial use is Auslogics Disk Defrag ( which seems to be more powerfull and still developped.

Created on Mar 21, 2014 9:11:23 PM by  nolme (0) 1



Your Vote:



Reading through this article it shows that 2008-R2 is preferred over 2012-R2. This article was last updated in 2011. Is this still the case ? I am upgrading my large installation to new hardware.

Created on Sep 17, 2014 10:30:44 AM by  Declan Costello (0) 1

Last change on Sep 18, 2014 11:59:40 AM by  Felix Saure [Paessler Support]



Your Vote:



Hello Declan,

Our latest speed tests have shown that Windows Server 2008 R2 offers the best performance. Nevertheless many customers are using Windows Server 2012 R2 for large installations without performance issues. The best way to reduce the load on the core server is to distribute your sensors to multiple remote probes.

Best regards

Created on Sep 18, 2014 12:13:02 PM by  Felix Saure [Paessler Support]



Your Vote:



Free Tip!

If you have installed PRTG on a vmWare Virtual Machine and if you are using HP ProLiant hardware, be sure the Power Profile is set to High Performance. It gives you a lot more performance! High vs dynamic power profile

Created on Oct 21, 2014 9:45:32 AM by  Martijn Goorman >> DataVisual (0)



Your Vote:



I just pushed past 40,000 sensors on a Vmware VM with 12 CPU cores, 48GB of RAM and a 2TB drive for the database.

I have hit a wall with disk performance. My average queue length is between 4 and 5 and disk is busy 95% of time.

All my sensors are SNMP ( with a handful of exceptions ) so they don't represent that much load. Most of them are on a remote probe but that doesn't really help that much with load on the core server. The database is really just a lot of files and this seems to be the limiting factor.

I am exploring options to improve performance given that I was given the vanilla storage option by our server team.

I use the API a lot to create devices and sensors based on data from our wireless management application ( a device per access point - we have 15,000 ). The API eats up memory and a long script creating devices or sensors has the possibility of crashing the server because of memory exhaustion.

The PRTG Core server does not seem to scale beyond 6 CPU cores. It only uses the last 6 of my available 12.

My server team doesn't want to give me real hardware but if they can't give me the storage performance I need on virtual I will need to insist on real servers.

Created on May 29, 2019 7:29:48 PM by  Ed McGuigan (190) 1 1



Your Vote:



Hello @GwigstaNummerEin

We do recommend to have hardware servers for an installation this large, but in order to improve the performance you are able to set the PRTG process to use all your 12 CPU cores available by setting the Processor Affinity in the task manager, you can refer to this guide Here. You can try setting the PRTG to use all 12 CPUs to see if the performance improves. This setting is reset in every reboot.

You can also try to increase the connection limit on VMware systems by following this article. Article

Created on May 30, 2019 5:49:47 PM by  Jonathan Mena [Paessler Technical Support]

Last change on May 30, 2019 5:50:24 PM by  Jonathan Mena [Paessler Technical Support]



Your Vote:



Hi Jonathan:

I am just looking at a utility to make affinity settings persist through restarts because I restart every night. We have another PRTG server with 22 cores so that needs it too.

I would prefer to run on real hardware with NVME storage but my hands are tied by internal bureaucracy and standards.

One other measure I did take was to put nginx as a reverse proxy in front of the server and I also use Firefox because it seems to load the web server less and provide a much snappier response time than Chrome.

Thanks for the reply.


Created on Jun 6, 2019 5:40:27 PM by  Ed McGuigan (190) 1 1



Your Vote:



With PRTG we manage an older windows 7 peer to peer LAN with just 17 devices. The core/probe, also an older PC, was having performance issue with WMI sensors.

Installing WMF 5.1 packages solved our issue. It included new bindings to COM objects for the WMI, WinRM and Powershell for Windows 7 SP1 that were never pushed by Microsoft but are available for download.

Created on Dec 4, 2020 4:56:08 PM by  aj (20) 1



Your Vote:



thanks for posting. solution above also applies to

Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 Windows 8.1

and is relevant to large installs where there might be remote prob on older systems

Created on Dec 11, 2020 9:17:34 PM by  aj (20) 1

Please log in or register to enter your reply.

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.