make SCOM Faster!!!
SCOM can be extremely slow and is a constant issue for our users, like embarrassingly slow...Not sure what it will take to improve the console speed but here are some suggestions:
Configure the views to be efficient out of the box.
Disable by default whatever is taking so long to load.
Re-design the database. More indexes.
Cache the views on the SCOM Console servers.
Make a better search function, so even if it is slow, users can quickly find what they are looking for.
Load pieces of the views at a time, like server name, then health state, then MM. Users are usually looking for a specific server anyways.
Anything to make the console faster.
We have started on some improvements to make the SCOM experience better. In 2016, we have particularly focused to improve the UI responsiveness for the monitoring experience. Please refer the blog for more details - https://blogs.technet.microsoft.com/momteam/2016/10/18/improved-ui-responsiveness-for-system-center-2016-operations-manager/
We are focusing on other areas, you will hear from us with several such incremental improvements.
Yes, SCOM, especially, but really ALL System Center products need a UI speed boost. The SCOM console is well-known for absolutely crawling. But it's not just SCOM. For example, I have a test SCSM environment (three server deployment with oodles of RAM and on a fast SAN) with maybe 20 incidents total and it takes 5 seconds to open an incident in the UI and you can actually see the form drawing itself like it's running on Windows 3.1. This is embarrassing.
This is THE issue with SCOM.
Sizing "limits" is the proof for a fundamental issue: "5000 servers with 50 consoles. 15.000 servers with 25 console". More servers usually means more ppl who have to work with monitoring.
All the investigestion i've done come down to SQL performance and some very terrible queries (mostly due to the dynamic nature of the database).
Frank Oelkuch commented
SCOM is in no way fast all the time.
When opening state views with more than 1000 objects and multiple class specific columns visible it takes ages to populate the view.
The same class with just base properties like Path and Health State opens in less than a second.
The same class with all properties from PowerShell retruns all objects in less than a second.
A single click on a state view results in hunderts of megabytes mesurable traffic between the MS and the SCOM console
SCOM is fast
A lot of scom admins just cant use it properly
John Moe commented
I've found that using Resource Manager on both the SCOM and SQL servers has helped identify some performance bottlenecks that I had and improved overall responsiveness, but I agree, there's a lot more room for improvement. CPU, RAM, network and disk are all sitting fairly idle (or at least have plenty of spare capacity) while I'm waiting for the console to update on my screen; what's taking so long?
Kelvin Chan commented
Totally agree with this, often when we go to SCOM, we want to search for state/alerts specific servers only. Instead of waiting for the whole list to be loaded (often takes too long to load), SCOM should allow users to search for specific server state/alerts without loading everything first.
Very good idea... our costumers get afraid every time they need to look for something in SCOM...
Good idea - as a user I often have to rely on querying the DW directly versus using the administrative console due to the slow performance.