Skip to content
Snippets Groups Projects
Domenico Giordano's avatar
Domenico Giordano authored
Qa

Closes BMK-1635

See merge request hep-benchmarks/hep-benchmark-suite!487
a860cb76
History

HEP Benchmark Suite

master
pipeline status
coverage report
code quality
License Python Support Latest Release
License: GPL v3 image Latest Release

Feedback/Support

Feedback and support questions are welcome primarily through GGUS tickets or in the HEP Benchmarks Project Discourse Forum.

For instructions on how to run the HEPScore23 benchmark, please refer to the dedicated HEPiX Benchmark page. The HEPScore23 scores for the benchmarked servers are reported in this table.

About

The HEP Benchmark Suite is a toolkit which orchestrates different benchmarks in one single application for characterizing the performance of individual and clustered heterogeneous hardware.

It is built in a modular approach to target the following use cases in HEP computing:

  1. Mimic the usage of WLCG resources for experiment workloads
    • Run workloads representative of the production applications running on WLCG.
  2. Allow collection of a configurable number of benchmarks
    • Enable performance studies on heterogeneous hardware.
  3. Collect the hardware metadata and the running conditions
    • Compare the benchmark outcome under similar conditions.
  4. Have prompt feedback about executed benchmarks
    • By publishing results to a monitoring system.
  5. Probe randomly assigned slots in a cloud environment
    • In production can suggest deletion and re-provisioning of under-performing resources.

For instructions on how to run the HEPScore23 benchmark, please refer to the dedicated HEPiX Benchmark page. The HEPScore23 scores for the benchmarked servers are reported in this table.

Benchmark suite architecture

The figure shows the high level architecture of the benchmark suite.

A configurable sequence of benchmarks may be launched by the HEP Benchmark Suite.

Benchmark results are aggregated into a single JSON document, together with the hardware metadata (CPU model, host name, Data Centre name, kernel version, etc.)

Optionally, the final report can be sent to a transport layer, to be further digested and analysed by broker consumers.

Users may also execute the suite in stand-alone mode without result reporting - see How to run for further details.

Integration status

The current Hep-Benchmark-Suite integration status.

  • Benchmarks
Benchmark Docker Singularity
HEPSpec06
SPEC2017
HEP-Score
  • Plugins
Plugin Status
HW-Metadata
ActiveMQ
OpenSearch

Available benchmarks

The HEP Benchmark Suite is delivered ready-to-run with a default yaml configuration file (see How to run). The currently available benchmarks are:

Due to proprietary license requirements, HS06 and SPEC CPU 2017 must be provided by the end user. This tool will work with either a pre-installed or tarball archive of SPEC software.

Example of HEP Benchmark Suite workflow

The above figure shows an example adoption of the HEP Benchmark suite for a multi-partition deployment.

Servers belonging to different data centres (or cloud providers) are benchmarked by executing the HEP Benchmark Suite in each of them. The mentioned servers can be bare metal servers as well as virtual machines. After running, the final JSON report is published to an AMQ message broker (shown as transport layer above).

In this example, an AMQ consumer may then digest the messages from the broker, and insert them in an Elasticsearch cluster so that the benchmark results can be aggregated and visualized in dashboards. Metadata (such as UID, CPU architecture, OS, Cloud name, IP address, etc.) are also included into the searchable results.

Users are free to build/use transport and aggregation/visualization tools of their choice to ingest the generated JSON results.

Quick Start: Running the Suite Examples

This is a short list of configuration examples to run the suite. For an in depth understanding of the installation and configuration options refer to the dedicated section

  1. HEPscore example runscripts:
  2. HEP SPEC example runscripts:
    • Run HS06 32 bits
    • Run HS06 64 bits
    • Run SPEC CPU 2017 Int Rate
    • Run SPEC CPU 2017 Rate cpp

You need to download the runscript you are interested in and run in the terminal.

Installation

This package requires pip3 >= 21.3.1, python3.6+ and git
If your pip3 --version is older, please update with: pip3 install --user --upgrade pip before installing!

Local user space

python3 -m pip install --user git+https://gitlab.cern.ch/hep-benchmarks/hep-benchmark-suite.git

This will install the suite to the user's home directory:

~/.local/bin/bmkrun

You can additionally add the executable to you $PATH:

export PATH=$PATH:~/.local/bin

Python virtual environments (minimum footprint)

There are cases on which the user would like to keep current Python3 library versions and have a minimum footprint of newly installed packages. For such purposes, it is possible to install the hep-benchmark-suite using Python Virtual Environments. This is the desired approach when the user requires a minimum footprint on the system.

export MYENV="bmk_env"        # Define the name of the environment.
python3 -m venv $MYENV        # Create a directory with the virtual environment.
source $MYENV/bin/activate    # Activate the environment.
python3 -m pip install git+https://gitlab.cern.ch/hep-benchmarks/hep-benchmark-suite.git

Note: When using virtual environments, hep-score will also be installed in this environment.

Limited connectivity (wheel installation)

An alternative installation method, not requiring git, is based on python wheels, which is suitable for environments with limited connectivity. All python wheels can be found here. For example:

export SUITE_VERSION=3.0
export SUITE_RELEASE=hep-benchmark-suite-wheels-3.0rc19-py39-none-linux_2_28_x86_64.tar 
wget https://hep-benchmarks.web.cern.ch/hep-benchmark-suite/releases/${SUITE_VERSION}/${SUITE_RELEASE}
tar -xvf ${SUITE_RELEASE}
python3 -m pip install suite_wheels*/*.whl

How to run

The python executable bmkrun can be added to the user's $PATH, and launched directly. The bmkrun requires one argument to be able to execute: --config. Users are free to provide command-line arguments, or edit the benchmarks.yml file directly.

  • Running the HEP Benchmark Suite with default configuration (hepscore is the default benchmark)

    bmkrun -c default
  • Execute with an alternative configuration

    bmkrun -c <config path>

Points of attention:

  • All CLI arguments have override effect. For instance, if user has defined multiple benchmarks on the configuration file and specify only one with the --benchmarks option, only this benchmark will be executed.

  • The aggregated results of the selected benchmarks are written to the location defined by the --rundir= argument or rundir in the yaml file.

  • By default, results are retained locally and are not transmitted to any remote endpoint, AMQ (the official approach), or OpenSearch (an alternative approach). To publish the results, please refer to the relevant sections: Advanced Message Queuing (AMQ), OpenSearch) section.

  • Benchmarks are executed in sequence.

  • The following benchmarks: hepscore, hs06, spec2017 are configured in their appropriate configuration sections.

  • If you want to run custom benchmark based on custom workloads you should follow the instructions described in hep-score and hep-workloads

  • In the case of running HS06, and/or SPEC CPU2017, the benchmark will look for the installation at the specified hepspec_volume:, and if it does not exist, it will attempt to install it via tarball argument url_tarball:, as defined in the benchmarks.yml).

  • Please have a look at the Examples section.

Plugins

Hardware metadata

The suite ships with a hardware metadata plugin which is responsible to collect system hardware and software information. This data is then compiled and reported in the results json file.

This plugin relies on system tools such as: lscpu, lshw, dmidecode. Some of these tools require escalated privileges for a complete output. Please take this into consideration if some outputs are empty in the final json report.

Read Plugins README.md for more information about the HEP Benchmark Suite Plugins.

Advanced Message Queuing (AMQ)

AMQ publishing is implemented using the STOMP protocol. Users must provide either a valid username/password or key/cert pair, in addition to the server and topic. The relevant section of the config yaml is given below. You must then pass the argument --publish to the suite.

username/password settings

activemq:
  server: some-server.com
  topic: /topic/my.topic
  username: user
  password: secret
  port: 12345

user cert settings

activemq:
  server: some-server.com
  topic: /topic/my.topic
  key: /path/key-file.key
  cert: /path/cert-file.pem
  port: 12345

Please note that key/cert authentication is preferred to publish the results to the CERN AMQ Broker.

In order to authenticate this way, you can request a grid user certificate from the CERN Certification Authority. There you can check whether you are elegible for a certificate as well as request the certificate itself.

As of 21 Jan 2025, the certificate is issued in a single PKCS#12 file (.p12) containing both the certificate and the key. So as to use it in this application, it needs to be split into a certificate and a key PEM file by:

openssl pkcs12 -in user.p12 -out user.crt.pem -clcerts -nokeys
openssl pkcs12 -in user.p12 -out user.key.pem -nocerts -nodes

Optionally, you can ommit the -nodes flag if you want to encrypt the private key. Then, to obtain the user DN in the format required by the Messaging Service (AMQ Broker) for the whitelisting, run:

openssl x509 -noout -in user.crt.pem -subject -nameopt RFC2253

which should output something similar to:

subject=CN=Name Surname,CN=123456,CN=username,OU=Users,OU=Organic Units,DC=cern,DC=ch

Pass this information to the Messaging Team alongside the server and topic to set up the authentication. Additional information on user certificates can be found at the official CERN CA documentation.

OpenSearch

OpenSearch publishing is implemented using the opensearch-py library. Users must provide a valid username/password, in addition to the server and index. The relevant section of the config yaml is given below. You must then pass the argument --publish to the suite.

username/password settings

opensearch:
  server: some-server.com
  index: my-index
  username: user
  password: secret
  port: 12345

Description of all arguments

The -h option provides an explanation of all command line arguments

$ bmkrun --help
-----------------------------------------------
High Energy Physics Benchmark Suite
-----------------------------------------------
This utility orchestrates several benchmarks

Author: Benchmarking Working Group
Contact: https://wlcg-discourse.web.cern.ch/c/hep-benchmarks

optional arguments:
  -h, --help            Show this help message and exit
  -b, --benchmarks BENCHMARKS [BENCHMARKS ...]
                        List of benchmarks
  -c, --config [CONFIG]
                        Configuration file to use (yaml format)
  -d, --rundir [RUNDIR]
                        Directory where benchmarks will be run
  -e, --export          Export all json and log files from rundir and
                        compresses them.
  -m, --mode [{singularity,docker}]
                        Run benchmarks in singularity or docker containers.
  -n, --ncores [NCORES] Number of cpus to run the benchmarks.
  -t, --tags            Enable reading of user tags from ENV variables
                        (BMKSUITE_TAG_{TAG}). Tags specified in configuration
                        file are ignored.
  -p, --publish         Enable reporting via AMQ/OpenSearch credentials in YAML file.
  -s, --show            Show running config and exit.
  -V, --extra_volumes VOLUME [VOLUME ...]
                        List of additional volumes to mount on the container.
  -v, --verbose         Enables verbose mode. Display debug messages.
  --version             Show program's version number and exit
-----------------------------------------------

Typical use cases

  • Show default configuration.

    bmkrun -c default --show
  • Specify custom tags via ENV variables.

    # All tags should start with BMKSUITE_TAG_
    export BMKSUITE_TAG_MYTAG="My custom tag"
    export BMKSUITE_TAG_SECONDTAG=$(uptime)
    
    # The --tags flag enables the reading of ENV variables
    # ignores tags specified in config file
    bmkrun -c default --tags
  • Run a test benchmark DB12 (should not be used for system benchmarking)

    bmkrun -c default -b db12
  • Run HS06 and SPEC2017. 64bit mode by default (Alternate config should be based on benchmarks.yml)

    bmkrun -c <alternate config>  -b hs06 spec2017
  • Parallel running (HPC, Cloud, etc)

    By default the suite pulls all workload images and files needed during execution. This traffic can be eliminated by pre-caching them in a shared location (dramatically speeding up runs across nodes that share access to a network storage, or where compute nodes have network restrictions).

    Before running with HEPscore:

    # set a common cachedir env to store a single copy of the images
    # this must be accessible across all nodes at the same mountpoint (or symlink)
    export SINGULARITY_CACHEDIR=/cephfs/user/johndoe/.singularity
    ./populate_image_cache.sh [optional yourconfig.yml]
    srun bmkrun -c <yourconfig.yml> # SLURM job submission for example

    where populate_image_cache.sh is used to pull all needed images before launching a benchmarking job. HS06/17 can load the SPEC distribution from a local file by setting the location to url_tarball: "file:/abs/path/HS06.tar.bz2"