Permalink
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
55 lines (41 sloc) 2.41 KB

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