You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Andrii Tkach (JIRA)" <ji...@apache.org> on 2013/12/20 13:30:10 UTC

[jira] [Created] (AMBARI-4133) Perf issues on Hosts page - freezes for several seconds and then unfreezes repeatedly on a large cluster

Andrii Tkach created AMBARI-4133:
------------------------------------

             Summary: Perf issues on Hosts page - freezes for several seconds and then unfreezes repeatedly on a large cluster
                 Key: AMBARI-4133
                 URL: https://issues.apache.org/jira/browse/AMBARI-4133
             Project: Ambari
          Issue Type: Task
    Affects Versions: 1.4.3
            Reporter: Andrii Tkach
            Assignee: Andrii Tkach
            Priority: Critical
             Fix For: 1.4.3
         Attachments: AMBARI-4133.patch

On a 600-node cluster, the Hosts page hangs for about 5 seconds and then unblocks for about 10 seconds, then freezes for 5 seconds, etc.
Chrome profiler shows that App.Host's *criticalAlertsCount* is eating up the CPU.  This is called by App.MainHostView's *hostCounts*, which is called by App.MainHostView's *label*.  This seems to be the cause for this freeze/unfreeze behavior. 

{code}
    criticalAlertsCount: function () {
      return App.router.get('clusterController.alerts').filterProperty('hostName', this.get('hostName')).filterProperty('isOk', false).filterProperty('ignoredForHosts', false).length;
    }.property('App.router.clusterController.alerts.length'), 
{code}

This piece of code gets called for every single host in the cluster every time we reload the alerts from the server.
There are several approaches to fix this problem:
1. The server should have alert info as part of the Host resource.  This way, we can simply map it and the client does not have to do much.  This will be done in Baikal via BUG-11704.
2. Since 1 won't be done until Baikal, we are left with the choice to improve efficiency of the front code.  Upon loading alerts, we can load them into a map so that look up by host (and service) would be fast; Ember's filterProperty is a linear search so it is very inefficient, especially on a large array, like a list of all alerts in the cluster and doing this over and over again for all the hosts in the cluster.  Also, we can sum up and store the aggregate count (like total number of hosts with critical alerts) as we map alerts.  I'm speculating that we can get a big perf boost just by doing these things.




--
This message was sent by Atlassian JIRA
(v6.1.4#6159)