Left list of resources on monitoring page has a popup window that let's you see the # of alerts and oob, with a "+" that let's you add metrics to the summary graphs page. However, all of the content of all of the popups are loaded at the time the page is loaded. For a page that has to show a large number of resources, this page load time can be very long. We need to only load the popups on-demand. If someone asks to see the information by hovering over the blue-right-arrow icon, only then should we load the content for that popup only.
Please define "very long". We are in the very few seconds for 1000 resources area (iirc). But as we are going to rewrite big parts of that anyway, we can surely have a look into this.
I think its more than a few seconds once you have alot of data in the database (alerts and OOBs). I don't have a current environment setup that demonstrates this, however. Another side effect of this is that the database is clobbered when you go to a page like this since it has to run those expensive queries for each resource in the left-hand tree.
see oracle-em.jpg - took 5 minutes to complete the query (I had closed my browser becaues otherwise, the refresh would continue to have executed the query)
i had 198 linux platform resources in my compat group. Left side wasn't too long in rendering but the summary graphs clobbered the DB (see attachment). The query took too long - the page refreshed before it could render the graphs.
would like this to be looked at for 1.2
Case 237156 is seeing this
Comment from Joseph on this general topic Charles: "Need to make sure the new monitor tab works well for big autogroups and compatible groups at various metric display ranges (40mins to 40days)." Joseph: After the migration to JSF, this is slightly better than it used to be...but only because I removed the automatic refresh mechanism that would crush things if you were viewing large groups. The page will load once, and the user needs to explicitly reload the data with F5. We could always add a refresh button to make this visually nicer. This won't get dramatically better until we change how we store and/or access that data.
Here (plan-1) is the plan for one of the metric graph rendering queries. I've not been able to find the plan for one of the super long ones, but this at least demonstrates where the work is going to. IIUC the raw table rotation this will be unioning two raw tables to get the last 8hrs worth of data. I've seen the group monitor tab render very slowly (>4mins for 450resources) when there should have be no unions required. One thing that is interesting in the above plan is that at one point we're doing a full table scan on RHQ_MEASUREMENT_SCHED table which is taking up a huge chunk of the CPU cost.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1002 Imported an attachment (id=368478) Imported an attachment (id=368479) This bug is related to RHQ-1955 This bug relates to RHQ-1103 This bug relates to RHQ-1213
Cross linking to the UI enhancement tracking bug, to make sure we cover this
Currently JSF, revisit after new graphing package (even though it's probably query based)
next release requires performance testing in general
remove superfluous blocks bz's