Optimize IPHost Network Monitor installation for best performance

Q: My IPHost installation works too slowly and creates high load on computer. Are there ways to enhance IPHost performance?

A: Optimizing IPHost installation for performance includes several steps. Please note that some of them should be done in case you change your monitoring setup significantly (for example, change alerting or other settings globally).

Note: the recommendations below assume you have installed the latest IPHost public release.

IPHost Network Monitor can be run either on physical computer, or within a virtualized environment (i.e., in a virtual machine). Below, when we write “computer”, we address both the cases.

Summary of steps to optimize IPHost performance

Upgrade to the latest IPHost Network Monitor version

We constantly work on improving IPHost Network Monitor. That includes fixing known product problems, enhancing efficiency, adding new features.

Using the latest version means you take advantage of using up-to-date software components, latest security-related modifications, latest added features. Our commercial licenses and freeware versions never expire; however, keeping your Maintenance&Support subscription active you make it possible to install the latest version of IPHost.

We encourage you to browse release notes records, to know of all the major changes brought by new releases.

To see what IPHost version you are currently using, run IPHost GUI client and select “Help > About IPHost Network Monitor”.

Allocate enough system resources

Although minimal system requirements require mere 512MB RAM (1GB for 50+ monitors), allow at least 4GB of RAM for big and/or busy IPHost installations. That will ensure all the IPHost software components utilize as much RAM as possible.

IPHost makes use of Firebird database engine (bundled with the product). On busy monitoring setups, fast disk I/O can become a bottleneck. When possible, use as fast storage devices as possible, to install IPHost to.

If you have more than one storage device (such as HDD) installed in your computer, you might gain significant system performance by placing monitoring database onto a faster disk drive.

To run monitoring polls concurrently, IPHost uses separate threads. It also tries using multiple concurrent TCP/IP connections wherever possible. To make sure these two groups of resources can provide best performance, start IPHost GUI client and in “Settings > Monitoring” adjust corresponding System limits:

  • set polling threads count to the amount of running monitors or 1000, whichever is smaller
  • set Maximum number of Web Transaction Processes 5-10 times as much as amount of active Web Transaction Monitors, to the amount of running monitors or 1000, whichever is smaller

System limits

Note: the above system limits can also be applied individually per every remote agent: navigate to “Settings > Remote Agents”, select an agent and click “Settings” button to adjust the system limits:

Agent system limits

Stop GUI client

IPHost GUI client is what you can use to initially setup and later tune your monitoring installation. It also allows viewing reports and current monitors state.

However, IPHost GUI client isn’t required for monitoring functioning. IPHost monitoring service is the workhorse that actually performs monitoring and does alerting. In case you do not use IPHost GUI client, you are advised to exit it (“File > Exit”), to free up system resources.

Read the forgotten manual

To assist you in everyday monitoring needs, we have added several reference sources. We encourage you to use them in the order provided below, to find the answer to your current monitoring inquire:

  • context help: press F1 while in IPHost GUI client, or visit online help in browser
  • make use of our extensive Knowledge Base, it contains answers to most frequently asked questions
  • use Search form on our site (present on every page) to look for possible answer (for example, try searching for “Remote Network Agent”)
  • visit our community site, to ask questions or look for already posted solutions
  • if all the previous options didn’t help, contact our tech. support; note that it operates on business days; customers owning commercial license(s) with active Maintenance&Support subscription get priority tech. support

In most cases you do not have to reach our tech.support to have your problem handled.

Avoid using resource-intensive applications along with IPHost

Monitoring can require relatively much resources (that includes RAM, CPU time, disk I/O and network bandwidth). Depending on many a factor (amount and types of active monitors, polling frequency, network latency etc), certain resources can easily become a bottleneck, preventing IPHost from working efficiently.

You can use Task Manager to see the mentioned resources utilization and find which applications try using much of them, save IPHost Network Monitor’s software components (IPHost monitoring service, bundled Web server and Firebird database engine).

The general rule of thumb is to avoid running anything else on busy and/or large IPHost monitoring installations.

Use remote network agents

If your license includes Remote Network Agents, and you have a lot of devices to monitor, try to make use of remove agents even if you have all the devices within the same network.

Using agents allows load balancing for monitoring tasks, distribute all the actual monitoring over several computers, thus making it simpler to get all the monitoring data in time. Note that if you use remote agents, make sure they have good connectivity with IPHost main installation.

To prevent getting multiple notifications when connection to an agent is broken, open the agent’s “Main parameters” tab and check the two options:

  • When connection with remote agent is broken or restored, send e-mail to (to get notified when agent is (dis)connected)
  • Stop if connection with remote agent cannot be established (to stop polling attempts for monitors on the disconnected agent)

The two options are underlined with green:

Agent main parameters

Ensure that dependency options are inherited for all the agent’s monitors. You can explicitly uncheck that option for a single monitor under the agent, to allow it sending notifications when the agent is unavailable.

That way, you will avoid getting a number of false alarms if connectivity to agent-hosting system gets shortly interrupted.

Poll resources infrequently

One can be tempted to poll the monitors as frequently as possible, to get alerted as quickly as possible. However, there are several reasons to set monitoring polling interval to 1 minute or less frequently:

  • too frequent polling means creating additional load on the device being monitored
  • frequent polling means frequent writing to disk (every poll result is stored into monitoring database)
  • in busy networks, frequent polls may result in greater amount of false alarms (due to temporary connectivity slowdown)

One minute is a good poll interval in most cases; if resources gets updated infrequently and/or is not of critical importance, raise polling interval further. If, for example, resource is updated on hourly basis, it makes little sense to request it every minute.

You might wish to set a few PING monitors to polling intervals of 30 seconds and make other resource-consuming monitors polled less frequently and depend on the mentioned PING monitors. That would mean less load on monitoring system and less alerts in case of interrupted connectivity.

Use lighter monitors

Different monitor types may require different amount of resources (such as threads, sockets, virtual memory, connections to other resources, running programs etc). To solve one’s particular monitoring task, it is advised to use as lightweight monitor as possible. An average “weight” of monitor can be taken from the below list (the higher the monitor in the list, the “lighter” it is):

  • Basic connectivity: TCP, UDP, PING
  • HTTP(S) and DNS monitors
  • (other monitor types not listed explicitly)
  • SNMP-based monitors
  • WMI-based monitors
  • Web Transaction Monitor

“Run Script or Program” monitor types cannot be evaluated by “weight” in general, it depends on what exactly is being run.

If you absolutely need running a number of “heavy” monitors on a host (device), make sure they all depend on PING or other lighter monitor on the same device, to prevent resource-consuming monitors from running when connectivity is broken.

Watch IPHost installation health

IPHost Network Monitor monitoring setup itself should be watched and monitored, to prevent it from suddenly shutting down, thus stopping all monitoring altogether.

To ensure that IPHost monitoring installation runs smoothly and its possible problems are spotted as soon as possible, one can follow the below recommendations:

  • do not monitor IPHost installation via one of its agents; you won’t be notified if the main installation itself goes down
  • install another IPHost Network Monitor installation elsewhere for mutual monitoring, and/or monitor Web interface presence of main IPHost installation
  • set up a monitor to watch for monitoring database backups
  • set up a monitor to check monitoring database health (optionally creating its cleaned-up backup copies)

Same goes for several IPHost Network Monitor installations: you can create a monitor on every one of them, watching for health of other installations. That would provide higher chances you will get notified when any of the IPHost installations gets down.

Keep it simple and secure

You are advised to watch the latest news on our site (and subscribe to our newsletter, to get the latest product updates and pieces of advice). That would provide you with important updates, including those to strengthen security of your IPHost Network Monitor installations.

One of IPHost components that can create unnecessary load is its Web interface. Unless there are reasons not to do that, protect the Web interface with password (you might set up different access credentials to finely control access to Web interface).

Set up HTTPS access to Web interface, to diminish chances of intercepting authentication credentials to access the interface.

If you grant access to Web interface to several users and/or user groups, you might wish to only provide them with some of monitoring data (by creating custom Web interface pages).

Related topics