Submit a ticketCall us

AnnouncementsAre You “Flying Blind?”

When it comes to your complex IT infrastructure, you want to ensure you have a good grasp of what’s going on to avoid any fire drills that result from guesswork. Read our white paper to learn how proactively monitoring your IT environment can help your organization while giving you peace of mind.

Get your free white paper.

Home > Success Center > Network Performance Monitor (NPM) > Network Performance Monitor (NPM) Training > Free SolarWinds Training Videos - NPM > When to add polling engines - Video

When to add polling engines - Video

Updated July 26th, 2016 


This video (2:42) describes when to add polling engines and the options for deploying - distributed or centralized environments. 



  • Network Performance Monitor
  • Orion Core products

Video Transcription


Scalability is similar to adding “horsepower” to your Orion® deployment and come into play on larger Orion environments. Once an Orion server reaches around 10,000 elements, it is time to start looking at additional capacity.  In environments such as this, it is necessary to add additional polling engines to spread the load between multiple servers. This also allows a customer to scale up installed modules without the need for additional licenses for each module. Polling engines are machines dedicated strictly to gathering device statistics and can be deployed locally or remotely.  Since no two networks are the same, there are different architectures that cover both large and geographically disparate network deployments. 

The first architecture we will discuss is the centralized option. Each Orion instance can poll 10,000 elements without an additional polling engine.  By adding one additional polling engine, the “instance” of NPM can now handle roughly 20,000 elements, this is true for up to 100,000 total elements.  One of the main benefits of the centralized model is that as you add polling engines to scale up NPM, you are also able to increase capacity of the modules as well.  For instance, if you need additional capacity to monitor applications with Server & Application Monitor or SAM, adding a polling engine will increase the capacity of both NPM and SAM. 

The second option for scaling NPM is the distributed architecture.  This is typically done in larger, more geographically dispersed environments.  Deploying a distributed model is slightly more complex and requires additional planning, but in the end can provide a more fault tolerant, locally controlled monitoring solution.  This is accomplished by placing separate autonomous Orion servers at multiple locations and combining the monitored data into a single view with the Enterprise Operations Console.  

The Enterprise Operations Console (EOC) acts as a single pain of glass for multiple Orion instances. For example, if I have an Orion deployment in North America and another one in Europe, the EOC will show both instances including global alerts and events. Each instance is still separately maintained but rolls up information into a single unified interface. The administrator has the option to allow full local control over the monitoring environment yet maintain that enterprise-wide visibility.


Last modified