[ 
https://issues.apache.org/jira/browse/STORM-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14546900#comment-14546900
 ] 

ASF GitHub Bot commented on STORM-820:
--------------------------------------

Github user d2r commented on the pull request:

    https://github.com/apache/storm/pull/554#issuecomment-102667234
  
    This pull request requires some more scrutiny because of its size and to 
make sure it does not break functionality.
    
    Goals for this PR
    
    * New Nimbus Thrift calls:
       * getTopologyPageInfo
       * getComponentPageInfo
    * Nimbus Thrift call getTopologyInfo remains
    * Aggregates metrics on nimbus so that serialized data is much smaller for 
large, highly-connected topologies
    * Moves ui code to stats namespace
    * Iterates over heartbeats one time.
    * Thrift deserialization code avoids deserializing to symbols, preferring 
strings, since making a symbol out of a string like "600" results in a symbol 
600 and not an integer 600.  This can be very confusing to debug, and breaks 
key comparisons in places.
    * Removes some dead code and does a little refactoring in places.


> UI Topology & Component Pages have long load times with large, 
> highly-connected Topologies
> ------------------------------------------------------------------------------------------
>
>                 Key: STORM-820
>                 URL: https://issues.apache.org/jira/browse/STORM-820
>             Project: Apache Storm
>          Issue Type: Improvement
>    Affects Versions: 0.11.0
>            Reporter: Derek Dagit
>            Assignee: Derek Dagit
>
> In the UI, the Topology Page and the Component Page each make a 
> getTopologyInfoWithOpts thrift call to nimbus for executor heartbeat data. 
> Metrics from this data are then aggregated in by the UI daemon for display.
> When large topologies, with high-connectedness, are viewed in this way, the 
> load times for each page can be minutes long.  In addition, heap usage by the 
> nimbus JVM can grow substantially as data for each executor, component, & 
> stream is serialized to be sent to the UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to