jira.rhq-project.org has been archived and is now in read-only mode.

John Mazzitelli - 08/Apr/09 04:52 PM the CPU auto-group is slow only when going to the monitor>graphs subtab - the other tabs are snappy.

Greg Hinkle - 09/Apr/09 01:05 PM Slow spots Small autogroup pages (with only 8 CPUs) are slow (monitoring view) at least in perftest env Single resource views - the tree is slow   - test large single platform views because the tree loads every resource   - N+1 problem on resources (testing resource query through hibernate.jsp) (3 round trips to do: select res from Resource res where res.id = 500050)   - Tree has to be completely reloaded for any ajax stuff   - Security impact on perf (the separate query to load what resource ids you can see) Autogroups    - Autogroup monitoring tab is very slow Group views   - Trees in group views are slow because they load every resource and descendent in those groups   - N+1 problem multiplies with more resources in view Autogroup and compatible group metric views are real slow   - I remember that I accidentally made one of the UNIONS just a regular UNION when it should be a UNION ALL

Joseph Marques - 22/Apr/09 03:39 PM agent to server sync performance: instead of syncing measurement schedules O(N) times where N is the number of nodes in the tree under a platform, we only sync O(D) times where D is the depth of the tree; each sync now does a bulk insert...select to create all schedules for all resources at that level; alert template creation was moved to the server side; got rid of one whole set of round trips that were unnecessary due to incorrect synchronization logic when dealing with merging a resource; improved safety of InventoryManager by always ensuring that the resource container map is access via its synchronized wrapper performance of tree loads: got rid of the N(N(N+1)) problem here where a single tree load might be hitting the database thousands of times; using reporting queries to bypass the hibernate layer and build the in-memory tree structure by hand recursive groups: changed this from a fly weight object-layer solution to a native sql-based solution; recursive computations now take a fraction of the time because the roundtrips were reduced from potentially thousands to exactly 2; this speeds up setting/unsetting recursive bits on groups, adding resources to a recursive group, and all dynagroup calculations other misc perf fixes: * eager fetch XXXToOne relationships of resources, groups, and a few other objects to prevent unnecessary round trips * fixed N+1 problem when loading favorite resources and groups in the nav bar * fixed N+1 as well as N(N+1) problems on various resource and groups tabs, notably the alerts>history and operations>new subtabs * fixed several instances of loading the dataModel for tabular data displays multiple times * fixed favorite resource icon loading so it only makes one call per page instead of a dozen facets caching: all mica icons across the entire system are loaded once now at startup, and are only loaded when a plugin is deployed; not only did this hit the database for EVERY row that needed MICA icons, but it also had the N+1 problem causing us to perform hundreds of queries per page just to decide whether or not to render icons; this was changed to load ALL facets for all resource types in a single query, and then cache that in a static in-memory map pagination: get rid of loading the data for each table multiple times due to faulty logic in the PagedListDataModel that backs all tables graphs: serialized generation of graphs by using a SingleThreadedServlet model, this was necessary because the graph units were being corrupted; upon investigation it was determined that the HighLowChartServlet is not stateless (as required by spec) and were causing collisions amongst multiple charts on the same page