HEP Benchmark Suite
master |
---|
License | Python Support | Latest Release |
---|---|---|
- HEP Benchmark Suite
- Feedback/Support
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:
-
Mimic the usage of WLCG resources for experiment workloads
- Run workloads representative of the production applications running on WLCG.
-
Allow collection of a configurable number of benchmarks
- Enable performance studies on heterogeneous hardware.
-
Collect the hardware metadata and the running conditions
- Compare the benchmark outcome under similar conditions.
-
Have prompt feedback about executed benchmarks
- By publishing results to a monitoring system.
-
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:
- HEP-score
- HS06
- SPEC CPU2017
- Fast benchmarks (should not be used for performance measurements):
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
- HEPscore example runscripts:
- HEP SPEC example runscripts:
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+
andgit
If yourpip3 --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 orrundir
in theyaml
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 argumenturl_tarball:
, as defined in thebenchmarks.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"