Skip to content

Working with the Github Action

Jump to bottom
econesag edited this page Jun 27, 2022 · 7 revisions

In this page we will explore how our Github Action for measuring energy efficiency works and how to use it. A complete example of the usage is found in this repo, which contains the Rust JTQ developed for the Chionophile project, along with a configured benchmark.

Usage of the generic benchmark

This is a tool that allows the user to encapsulate and configure with a YAML file the functionality provided by the Goose Framework, eliminating the need to know Rust in order to use it.

Objective

Give the option to make load benchmarks in an efficient language like Rust without the need to know how to write it yourself.

Usage

The configuration options are the following:

  • host
  • port
  • use_https
  • base_path
  • users
  • goose_log
  • user_creation_rate
  • run_time
  • report_file
  • request_log
  • request_body
  • error_log
  • debug_log
  • max_request_second
  • no_reset_metric

All of them are explained in this page of the Goose documentation. The only changes are user_creation_rate and max_request_second that correspond with hatch_rate and throttle_requests respectively.

Under the benchmarks section you can define a series of request-groups that will fall under that benchmark name. Define as many benchmarks as you want with as many request-groups and individual requests as necessary.

Take into account that all of the requests in a request-group will be executed consecutively. That means that if an individual request fails, the rest of the group will not be executed.

The next options are designed to configure a DELETE request after a POST request:

  • should_delete
  • body_field_for_delete
  • delete_end_slash

If should_delete is true, the program will look for the indicated field in body_field_for_delete in the POST request's response. The delete_end_slash tells the program if a "/" should be added at the end of the URL.

For example:

  1. A POST request is made with the next URL /visitormanagement/v1/visitor/
  2. It returns the following response:
  {
    "id"¨: 123,
    "username": "[email protected]",
    "name": "pepe",
    "phoneNumber": "+34623456789",
    "password": "paco",
    "acceptedTerms": true,
    "acceptedCommercial": false
  }
  1. should_delete is true
  2. body_field_for_delete is "id"
  3. The program looks for the "id" field in the previous response
  4. If delete_end_slash is true, it makes a DELETE request with this URL: /visitormanagement/v1/visitor/123/
  5. If delete_end_slash is false, it makes a DELETE request with this URL: /visitormanagement/v1/visitor/123

A functioning example of a config.yaml file can be found here.

Usage with an On-Premises server

The main branch of the Github action can accurately measure the consumption of your BackEnd software in a Windows On-Premises server, using Intel Power Gadget as the measuring tool. There is no need to add the whole workflow to your project, because it can be added as a remote workflow.

Requisites

  1. A machine configured as a self-hosted runner for your Github repository, with Docker and Docker Compose installed
  2. If your repository is private, you need to have an alternate public repo to deploy your results in HTML as a Github Page
  3. A configuration file for the Generic Benchmark adapted to your server, located in the root folder of your repository
  4. A Docker Compose file that can launch a complete instance of your server, and if needed, the database
  5. The self-hosted runner must have the server port open, in order for the Github Actions server to be able to make requests to it

Workflow

  1. Self-Hosted Runner: If your server was already running in the self-hosted machine, closes it.
  2. Self-Hosted Runner: Launches a new instance of the server
  3. Self-Hosted Runner: Starts the energy measurement, that will last the amount of time configured in the generic benchmark
  4. Github Actions Server: Starts the benchmark using your pre-configured YAML
  5. Github Actions Server: Cleans up the HTML and deploys the results to your public repository's Github Pages

Usage with AWS

The aws branch of the Github action can estimate the consumption of your backend server deployed in an EC2 instance.

The action just needs the next env variables to be set:

  • INPUT_NAMESPACE (ex: "AWS/EC2")
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY
  • AWS_DEFAULT_REGION (ex: eu-west-1)
  • config (default=config.yaml)

This variables are needed to access cloudwatch and get the cpu utilization of the desired instance.

Contents

Clone this wiki locally