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:
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.