What is the impact of the OpsMgr Web Console on the RMS?

This week I had a conversation with a customer who wanted to offer their admins OpsMgr Web Consoles instead of the “normal” fat-client OpsMgr Consoles. Most customers think that the Web Console would have less impact on the RSM as the “normal” fat-client.

But when we look in the Operations Manager 2007 Performance and Scalability Guide and look at what impacts the performance of the RMS we read:

Factors that influence the load on the root management server include:

• Number of Agents in the management group. Because the root management server must compute the configuration for all agents in the management group, increasing the number of agents increases the amount of memory required by the root management server, regardless of how much operational data the agents send, such as alerts, events, performance data, etc.
• Rate of instance space changes. The instance space is the data that Operations Manager maintains to describe all of the monitored computers, services, and applications in the management group. When this data changes frequently, additional resources are needed by the root management server to compute configuration updates for the affected agents. The rate of instance space changes increases as you import additional Management Packs into your management group. Adding new agents to the management group also temporarily increases the rate of instance space changes. Seeing a consistently high rate of instance space changes might indicate that the Management Packs you imported need tuning to send discovery data less frequently.
• Number of Operations Consoles and other SDK clients running simultaneously. Examples of other SDK clients include the Web console and many third-party tools that interface with Operations Manager. Because the SDK Service is hosted on the root management server, each additional connection uses memory and CPU.

And because the Web Console is a SDK Client just like the “normal” OpsMgr Console, you could conclude that the Web Console has the same impact on the RMS as the “normal” OpsMgr Console. But what happens when you use the Web Console in OpsMgr 2007 R2? The R2 Web Console opens the connection, then caches the connection instance in the Session on the server and reuses for all subsequent requests. The connection is not closed explicitly. As said earlier the Web Console uses the same API calls as the “normal” OpsMgr Console.

The major difference between the Web Console and the OpsMgr Console is the OpsMgr Console local cache. So you could say the Web Console has more impact on the RMS just because it queries the RMS each time that data is needed, versus the OpsMgr Console looking in the local cache first.

You can configure the Web Console settings via the web.config file. My colleague Micheal Pearson has written a blogarticle about which settings can be configured. You could limit the rows in your Alert Views or State views, but this is done on the Web Server hosting the OpsMgr Web Console. Still all data is queried via the SDK on the databases. The web.config settings controls the rendering, that is how much data is transferred from the web server to the client.

Hope this clarifies the difference between the Web Console and OpsMgr Console and their impact on the RMS. I want to thank Michael Pearson and Alexander Netrebchenko for helping with topic.

Tweet

Comments

• Anonymous
  March 15, 2011
  Hi Stefan, Don’t forget to mention that the load time of the navigation tree on the web console is way to slow in comparison with the native console. In my experience makes this the web console only workable for adhoc work. Michel