Skip to content

Latest commit

 

History

History
54 lines (41 loc) · 2.41 KB

007_2016-08-19.md

File metadata and controls

54 lines (41 loc) · 2.41 KB
Raw

Report 007 - August 19, 2016

Aggregation over all available performance metrics

  • All performance metrics available in FWJRs are now dynamically aggregated and can be retrieved from the server. These include:

    {
    "count": Integer,
    "events" : Integer,
    "performance" : {
        "multicore" : {},
        "cpu" : {
            "TotalJobTime" : Float(seconds),
            "TotalJobCPU" : Float,
            // ...
        },
        "storage" : {
            "writeTotalMB" : Float(MB),
            "readTotalMB" : Float(MB),
            // ...
        },
        "memory" : {
            "PeakValueRss" : Float(MB),
            // ...
        }
    }
}

  • For now only a subset of these metrics is accessible in the UI. The specific metrics to be displayed along with their display name and value formatting shall be discussed soon.

  • So far for each of these metrics the aggregation procedure computes their average across the FWJRs along with the number of FWJRs aggregated over, since not every FWJR provides a value for every metric.

Finalized Scope

  • Added the exitCode scope filter in Report 005.
  • This completes the preliminary final set of scope filters. Tests will now determine if this set of scope filters is sufficient to provide a useful service to CMS data operators.

Dynamic visualization handling

  • Rearchitected the performance data fetching in the web app to allow for a more responsive UX. Instead of a single API call to fetch the entire dataset whenever a scope, metric or axis selection changes, the web app now handles the visualizations separately.
  • The list of visualizations is constructed dynamically from the user's selection of metrics and axes.
  • Data for a visualization is fetched only on creation and on scope changes.
  • Suggestions for scope filters are fetched separately.
  • This allows the UI to reflect the user's choice of visualizations immediately, displaying a loading indicator whenever the data for a visualization is not yet available. It also reduces request payloads, resulting in faster page loads.

Prototype deployment

  • I fixed a number of issues and implemented improvements to finalize a first deployment of the WMArchive performance prototype to the CMS testbed:

    Prototype