New Question
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.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:



For a few hundred sensors PRTG usually doesn't show any speed and performance problems. But with thousands of sensors one may experience excessive CPU load, slow web interface or sensors that are not scanned at the specified intervals.

So what can I do to make PRTG work faster, use fewer system resources, work more reliable?

  • What things are to consider before installation?
  • What are "best practices" for large installations of PRTG?
  • What can I do to make the user experience faster, especially the 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 [Paessler Support]

Last change on Mar 31, 2011 10:38:15 AM by  Daniel Zobel [Paessler Support]

8 Replies

Accepted Answer



Your Vote:



This article applies to PRTG Network Monitor 14.4.12 or later

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.

Real Servers are Better than Virtual Servers

Especially when running installations with a high number of sensors (beyond 1,000), real hardware often performs better than virtual environments. We have seen very performant VMs that could not beat real hardware (due to network and disk speed bottle necks). So if your system slows down on a virtual server, try moving PRTG to real hardware.

We strongly recommend that you use "bare metal" for installations of up to 5,000 sensors and regard it mandatory for more than 5,000 sensors. In these cases you should run at least the core server on real hardware, whereas you may install remote probes on virtual machines.

If your PRTG core server or remote probe is running in a VM, please make sure to 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 will increase the CPU performance compared to the multi-socket single-core configuration which may result in serious performance issues within the VM.

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.

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 Memory

More available memory can significantly improve the speed of PRTG.

  • 32-Bit OS: Install 4 GB of RAM memory. This will maximize the available RAM and disk cache.
  • 64-bit OS: Install at least 4 GB of RAM memory, 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, please 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

Best operating systems for PRTG, in order of performance:

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

Avoid Windows Vista and Windows 2008 R1 at All Cost

Both Vista and the first edition of Windows Server 2008 have serious performance issues, especially when using WMI. Do not use them for large installations!

Note: Windows Vista is not officially supported. Please 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 using 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, please see "More Resources" section below.

3. PRTG Server Settings

You can win a lot by a smart configuration of your PRTG server!

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 memory usage. Choose the smallest settings that still make sense for your use case. The objective is to avoid slow memory swapping at all cost.

Graph Settings in PRTG System Administration

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

Switch on the "Speed" Option

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, please see What does PRTG's "More Speed" option do?

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

Switch PRTG's 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. Without encryption the internal web server 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, log in to the PRTG web interface and manually call the /speedtest.htm URL in your browser, so you can measure the success of any optimization efforts. 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 of your sensors from 1 minute to 5 minute intervals. Hint: Change the interval in the Root group settings and use PRTG's inheritance mechanism 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 produces a certain load. Minimize the number of scheduled auto-discoveries whenever possible. Especially, do not schedule an auto-discovery to run every hour. If possible, set the discovery schedules to Once and run 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

Use SNMP V2c, Avoid V3

SNMP V3 doesn't 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 doesn't 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 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, 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 of high bandwidth networks, NetFlow and sFlow are far more efficient than Packet Sniffing. For details, see PRTG Manual: Bandwidth Monitoring Comparison.

Minimize 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 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 disables similar sensors detection automatically if your installation exceeds 1,000 sensors. If you want to keep the system load of PRTG at a minimum even for smaller installations, turn off the analysis completely.

Turn Off Recommended Sensors Detection

With the recommended default setting, PRTG disables the detection engine automatically if your installation exceeds 5,000 sensors. If you want to keep the system load of PRTG at 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 rebooted once a month. Consider automatic reboots as often as once per week also for systems that run heavily used Remote Probes.

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

Note: In previous PRTG versions, you could 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 log files 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 parallel 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 automated daily or weekly.

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, leading 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, please see this article.

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,834) 3 4

Last change on Nov 15, 2018 1:06:47 PM by  Sebastian Kniege [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 [Paessler Support]



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,834) 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)

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.