Can someone explain in some detail what the difference in performance
would be (if any) in using Filtered Event Views based on the Server View
generated from different Membership Rules in a Management Group for me

For instance:
Using an MG Membership Property of Repository "View" of Master for each
QDB versus using a Rule such as "AppManager Installed" with
"Repositories Greater than" or versus just using a simple static
"List" inclusion.

Is one type of Membership more dynamic (based on a SQL View or QDB
Master View) and need to be parsed more often than a simple Rule-based
How often does the Membership get refreshed?
Is there a limit to the number of Filtered Event Views placed onto a
Service Map before seeing degradation in performance of Svc Map load
What are some other 'tweaks' that can be done to improve load times for
Service Maps and avoid timeouts? (config timeout edited to allow up to 3
minutes already) BTW - We do not have embedded service maps in use
Does applying Permissions to an MG (with all servers) also affect
Service Map load times also?
Another observation is that we have other service maps which will load
relatively quickly but they are built with Filtered Event Views on a
much smaller subset of Server Views (other MGs)

Need to have multiple Filtered Event Views (~16) that apply to ALL
Servers (~500) on multiple QDBs and we are experiencing quite a deal of
latency on loading of Service Map and sometimes if fails to load
altogether. All of these Filtered Event Views have only a few "Server
Filters" and none of them are based on Server. Most "Server Filters"
are "Severity Less Than Or Equal To 20" and Knowledge Script "Is Like
NT_Service*". Since our Operations Staff needs to watch all Servers for
certain conditions like Disk, Hardware, Down Servers, etc. we have to
have Event View reflect all Servers.

armstrongge's Profile:
View this thread: