Why is the new values per second setting so important? While knowing how many hosts or even items a system has is important, the underlying load could vary a lot. For example, we could have a system with 1,000 hosts, with 100 items each, but the items would be polled once every 15 minutes. In this case, the approximate expected New Values Per Second (NVPS) would be 111. Or, we could have only 10 hosts with 100 items per host, but if the interval were 10 seconds (that's a very low interval; if possible, never use such a low interval), the total expected NVPS would be 100. As we can see, host and item count have an impact, but so does the average interval. NVPS is a generic value that can be compared to other systems more easily. In our installation, the expected NVPS, based on our current host and item configuration, is likely to be somewhere between seven and nine. This means that, every second, the Zabbix server is expected to receive and process that many historical values; this also includes calculating any trigger expressions, calculating trend information for numeric items, and storing any resulting events and these historical values in the database. It's quite a lot of seemingly invisible work for each value.

We can see the value for the current configuration in the Zabbix status report, but how can we calculate the expected NVPS for a larger system we're building, without adding all of the hosts and items? If we had 60 items on a single host, each polled once per minute, the NVPS could be calculated like this:

<item count> / <item interval> 

So, 60 items per minute would result in one NVPS. By the way, one item per minute would be 1/60 or 0.01557. To get the total NVPS in the projected environment, we would simply multiply it all by the amount of hosts:

<average item count per host> / <average item interval> * <total host count> 

Plug in various values and see how the expected NVPS changes as one of these values is changed. The more hosts you have, the more impact the average interval and average item count per host will have.

The value that the frontend gives us is a nice way to determine the expected NVPS right now, but it isn't that easy to see how it's changed over time and how configuration changes have impacted it.

We can add an internal item that'll store this value so that we can see long-term changes and graph them:

1. Navigate to Configuration | Hosts, click on Items for A test host, and then click on the Create item button.
2. In this form, start by clicking on Select next to the Key field, and change the Type drop-down menu to Zabbix internal in the item helper.

This presents us with a nice list of the available internal items. We'll set up a few of these, but won't discuss every single item in there. If you're curious about some after we're done with this topic, consult the Zabbix manual for detailed information on each internal item. Remember how we created an item to monitor the time when the proxy last contacted the server? That was also an internal item.

In this list, click on zabbix[requiredperformance]. Fill in the following:

• • Name: Expected NVPS
  • Type: Zabbix internal
  • Type of information: Numeric (float)
  • Units: NVPS
  • New application: Zabbix performance

3. When done, click on the Add button at the bottom.

Check this item in the Latest data page. After a short while, it should have the value—somewhat similar to what we saw in the Zabbix status report:

This value is likely to be different than the one we saw in the report. We just added an item to monitor the expected NVPS, which provides values of its own, so this action has affected the NVPS already.

With this item configured, let's talk about what it actually is. You might've noticed how it was stressed many times before that this is the expected NVPS. It's based on our host and item configuration and doesn't actually reflect how many values we're receiving. If we had all of the items of the active agent type and all agents were stopped, the expected NVPS wouldn't change, even though we would receive no information at all. Barring such technical issues, this number could differ from the values we normally process because of other reasons. Log monitoring items are always counted according to their interval. If we have a log item with an interval of one second, it's included as one NVPS even if the log file itself gets no values—or if it gets 10 values every second. Flexible intervals and item scheduling are ignored, and trapper items aren't included in the expected NVPS estimate at all. If we send a lot of values to trapper items, our real, processed NVPS will be higher than the expected NVPS—sometimes several times higher.

As the expected or estimated NVPS can be inaccurate, we also have a way to figure out the real NVPS value; there's another internal item for that purpose.

Let's go back to Configuration | Hosts and then Items for A test host again and click on Create item. Fill in the following values:

• Name: Real NVPS
• Type: Zabbix internal
• Key: zabbix[wcache,values]
• Type of information: Numeric (float)
• Units: NVPS
• Preprocessing: Change per second
• Applications: Zabbix performance

When done, click on the Add button at the bottom. In the Key, we used the keywords, wcache and values. The first one is supposed to stand for write cache, or we can think of it as a cache of the values to be written to the database. The values parameter tells it to report the number of values passing through that cache. We'll look at other possible parameters a bit later.

Another thing worth noting is the Store value; this internal item reports a counter of all values, and this way, we're getting the number of values per second. We both obtain a value, easily comparable with the expected NVPS, and avoid a hill graph. How would we know which internal items return a final value and which ones are counter items? Consult the Zabbix manual as usual.

With the item in place, let's compare the expected and real values in the latest data page:

Notice how the expected NVPS value increased again after adding another item.

In this system, parts of the monitoring infrastructure are down, so the real NVPS value is significantly lower than the expected one. You might want to mark the checkboxes next to both of these items and display an ad hoc graph to visually compare the values and see how they change over time. The expected NVPS is likely to be pretty stable, only changing when the configuration is changed. The real NVPS is likely to go up and down as the value retrieval and processing changes over time.