Bug 707224

Summary: Evaluate and improve RHQ performance and scalability
Product: [Other] RHQ Project Reporter: Charles Crouch <ccrouch>
Component: PerformanceAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Mike Foley <mfoley>
Severity: unspecified Docs Contact:
Priority: urgent    
Version: 4.0.0CC: ccrouch, hbrock, hrupp, jshaughn
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-04 04:25:44 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 620933    

Description Charles Crouch 2011-05-24 09:08:14 EDT
This is a tracking issue for improving the scalability of RHQ. The effort should cover a number of distinct aspects

1) Backend service scalability testing (agents, metrics, events, calltime)
Similar to what we've done for previous JON releases, but with a focus on automation. The goal here is two fold, make sure JON3.0 performs better than previous releases and build out a testing platform which can be used if in the future we need to test alternative implementations for metric, event and calltime storage and retrieval.
2) UI scalability testing (performance of standard setup, concurrent users, large inventory). Again the goal is to improve upon the load footprint and concurrent users offered by previous JON versions.
3) Scalability of our JBAS7/EAP6 integration in terms of:
a) number of concurrent instances we can monitor/managed on a given host
b) total number of instances which can be monitor/managed by a given cluster of JON servers
There is obviously some intersection here with the JBAS7/EAP6 work (https://bugzilla.redhat.com/show_bug.cgi?id=707223)
4) With an eye to the future (post JON3) investigate what techniques/technologies would be suitable to enable JON to scale 2x, 5x, 10x beyond where it is currently. My expectation is that during the above evaluation for JON3, architectural bottlenecks will be found in 1) versus 2) or 3), in which case we should investigate what options are available for improving our backend service scalability, in particular the metric storage system. With respect to the metric subsystem in particular, any investigation should include a review of how this data will be displayed to the user through any new metric charting implementation (e.g. as we change/optimize the metric storage its ok to change how/what precisely we display if that helps provide a more scalable architecture)