Bug 534181 - (RHQ-1002) graph of metrics on monitor tab loads is slow for large group
graph of metrics on monitor tab loads is slow for large group
Product: RHQ Project
Classification: Other
Component: Performance (Show other bugs)
All All
high Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
: Improvement
Depends On: RHQ-1265 RHQ-1448
Blocks: rhq-perf
  Show dependency treegraph
Reported: 2008-10-21 09:22 EDT by John Mazzitelli
Modified: 2013-12-07 10:40 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-07 10:40:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
oracle-em.jpg (99.49 KB, image/jpeg)
2008-11-06 15:51 EST, John Mazzitelli
no flags Details
plan-1.jpg (245.19 KB, image/jpeg)
2009-01-29 19:58 EST, Charles Crouch
no flags Details

  None (edit)
Description John Mazzitelli 2008-10-21 09:22:00 EDT
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.
Comment 1 Heiko W. Rupp 2008-10-21 09:31:45 EDT
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.
Comment 2 John Mazzitelli 2008-10-21 09:39:22 EDT
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.

Comment 3 John Mazzitelli 2008-11-06 15:51:42 EST
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)
Comment 4 John Mazzitelli 2008-11-06 15:52:42 EST
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.
Comment 5 John Mazzitelli 2008-11-06 15:53:39 EST
would like this to be looked at for 1.2
Comment 6 Charles Crouch 2008-11-11 12:22:08 EST
Case 237156 is seeing this
Comment 7 Charles Crouch 2009-01-12 14:16:23 EST
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.
Comment 8 Charles Crouch 2009-01-29 19:58:23 EST
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.
Comment 9 Red Hat Bugzilla 2009-11-10 15:21:37 EST
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
Comment 10 Charles Crouch 2010-08-03 15:38:45 EDT
Cross linking to the UI enhancement tracking bug, to make sure we cover this
Comment 11 Jay Shaughnessy 2011-02-11 16:12:56 EST
Currently JSF, revisit after new graphing package (even though it's probably query based)
Comment 12 John Mazzitelli 2011-04-01 11:20:13 EDT
next release requires performance testing in general
Comment 13 Charles Crouch 2011-09-30 19:28:12 EDT
remove superfluous blocks bz's

Note You need to log in before you can comment on or make changes to this bug.