as it stands today, group plugin configuration updates have been tested and work against resource groups as large as 20K resources, but the time it takes for such an update to complete is rather long. we're talking on the order of 50 updates / minute right now. pretty much, it comes down to the fact that each individual plugin update makes a separate request to the agent, and afterwards sits around and waits for a new service discovery to complete. there is definitively room for improvement here. we could re-order the group update so as to batch the updates to each agent, and perform a single request for service discovery after all of the resources on any one agent complete. this could easily make the end-to-end time 10, 20, or even 30 times faster. the speed-up would be determined by the number of plugin configurations being updated on each agent; the more updates per agent, the greater the speed-up (for that sub-part of the end-to-end flow).
actually, i think the best way to achieve this is to simply support executing runtime discoveries from a particular root resource as opposed to the entire hierarchy. this way, the server-side could blindly submit runtime discovery requests to an agent for multiple resources on a single agent without worrying that work will be duplicated.
this is a performance-related issue, so pushing to 2.0
this is no longer an issue. Ian already performed a full round of performance-related testing for group configuration when writing the configSet component. furthermore, this has gotten extensive coverage in the perf env for the 1.2 release.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-417 This bug relates to RHQ-486