Red Hat Bugzilla – Full Text Bug Listing
|Summary:||need to make alert query more efficient for "recent alert count" display|
|Product:||[Other] RHQ Project||Reporter:||John Mazzitelli <mazz>|
|Component:||Core UI||Assignee:||Charles Crouch <ccrouch>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike Foley <mfoley>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-09-02 03:14:01 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description John Mazzitelli 2010-11-24 17:50:17 EST
We need to change the API the UI client uses to get the alert count (the count you see in the bottom right of the UI, where it says "[#] Recent Alerts". right now it ends up calling: org.rhq.enterprise.server.alert.AlertManagerBean.findAlertsByCriteria(Subject, AlertCriteria) which queries and returns much too much data for this usage of it. All we need to do is do a count query and return a single integer. Instead, we are returning all Alert objects, including all conditions sets!
Comment 1 John Mazzitelli 2010-11-24 17:54:16 EST
looks like the criteria uses limits the page size to 1 row, so this isn't as bad as it first looked by code inspection. // only get one record from the first page, we only really care about the count alertCriteria.setPaging(0, 1); But we really still don't have to send that much data (remember, this query is periodically called every 1 minute for EVERY user).
Comment 2 Joseph Marques 2010-11-24 18:20:07 EST
commit ec43cd6bf1be52a0a101f85faf654610b27c6df6 Author: Joseph Marques <firstname.lastname@example.org> Date: Wed Nov 24 18:17:10 2010 -0500 BZ-657107: support querying alert count by criteria (and show in footer)
Comment 6 Mike Foley 2011-06-15 15:29:38 EDT
tested alerts. from an empirical standpoint, i am seeing response time < 10 seconds (arbitrary performance SLA) in the alert area. when alerts are slow, it seems to be related entirely to the UI layer with CPU utilization at 100% attributed to Firefox browser and not the server response time. there is a more full-blown performance effort underway, and fully intend to identify and optimize performance from that perspective.
Comment 7 Heiko W. Rupp 2013-09-02 03:14:01 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.