- 3 minutes to read

Polling Frequency

This troubleshooting guide explains how polling frequency affects metrics collection, sampling rate, real-time monitoring, and alert latency in the Nodinite JMX Monitoring Agent, also referred to here as the JMX Agent.

Understanding Polling Frequency

The polling frequency determines how often the JMX Monitoring Agent queries the Spring Boot Gateway for updated JVM metrics. A higher polling interval provides more granular data and faster alert detection, but increases CPU overhead and network traffic.

graph LR A[" Polling Timer"] -->|Every N seconds| B[" JMX Monitoring Agent (IIS)"] B -->|HTTP request| C["fab:fa-java Spring Boot Gateway"] C -->|JMX query| D[" Target JVM"] D -->|Metrics response| C C -->|JSON response| B B -->|Evaluation| E{" Threshold\nExceeded?"} E -->|Yes| F[" Alert Sent"] E -->|No| A style A fill:#87CEEB style F fill:#FF6B6B

Diagram: Polling cycle showing how the JMX Monitoring Agent collects metrics from the Spring Boot Gateway at each polling interval.

Scenario Recommended Interval Rationale
Production — critical JVMs 30–60 seconds Fast detection, minimal overhead
Production — standard JVMs 60–120 seconds Balance resolution and overhead
Test / QA environments 120–300 seconds Reduce monitoring overhead
Development environments 300 seconds Minimize noise during development
High-volume JVM clusters 60 seconds Consistent monitoring across cluster

Tip

For Boomi Atoms running critical integration processes, a 30–60 second polling interval provides fast detection of CPU and memory issues that could impact message processing SLAs.

Impact of Polling Frequency on Alerting

The polling interval directly affects the minimum alert latency, the time between a threshold breach and the first alert:

  • A 60-second polling interval means an alert may be delayed up to 60 seconds after the threshold is first breached
  • The Duration threshold (set in JMX Configuration) adds additional time: Duration / Polling Interval = number of poll cycles required to fire an alert

Example Alert Timing Calculation

With a 60-second polling interval and a 180-second Duration:

  • Threshold breaches at T=0
  • First detection at T=60 (first poll after breach)
  • Alert fires at T=180 (Duration satisfied across 3 poll cycles)
  • Total latency: 3 minutes

Performance Considerations

JVM Overhead

JMX queries impose minimal overhead on the target JVM. Standard JMX metrics such as heap memory, CPU usage, and thread count are sampled counters that the JVM maintains internally. The overhead per poll is typically less than 1ms of CPU time.

Network Traffic

Each poll generates a small HTTP request to the Spring Boot Gateway. For 10 JVMs polled every 60 seconds:

  • Approximately 600 requests per hour per monitored JVM group
  • Each response is typically 1–5 KB
  • Total network overhead: negligible (< 1 MB/hour)

Note

If you monitor JVMs across a WAN link, for example remote data center JVMs, increase the polling interval to 120–300 seconds to reduce WAN traffic and accommodate higher network latency.

Next Step

Multi-JVM Monitoring
OS vs JVM Monitoring

Environment-Specific Thresholds
Correlate Heap Spikes
JMX Troubleshooting Overview