Rate Controllers

HH·2022년 1월 9일
1

Hyperledger Caliper

목록 보기
9/12

Rate Controllers

트랜잭션이 블록체인 시스템에 입력되는 비율은 성능 테스트 내의 키 펙터이다. 지정된 비율로 트랜잭션을 보내거나 특정한 프로필을 따르도록 하는 것이 적절할 수 있다. 캘리퍼는 사용자가 사용자 정의 로딩 메커니즘에서 성능을 테스트할 수 있도록 사용자 정의 레이트 컨트롤러 사양을 허용한다. 유저는 자신만의 레이트 컨트롤러를 지정하거나 아래 디폴트 옵션 중 하나를 선택할 수 있다 :

  • Fixed rate (고정 비율)
  • Fixed feedback rate (고정 피드백 비율)
  • Fixed load (고정 부하)
  • Maximum rate (최대 비율)
  • Linear rate (선형 비율)
  • Composite rate (복합 비율)
  • Zero rate (영비율)
  • Record rate (기록 비율)
  • Replay rate (반복 비율)

사용자 지정 레이트 컨트롤러 구현은 커스텀 컨트롤러 추가를 참조한다.

Fixed rate (고정 비율)


고정 비율 컨트롤러는 가장 기본적인 컨트롤러로, 컨트롤러가 지정되지 않으면 사용되는 디폴트 옵션이기도 하다. 이는 인풋 트랜잭션을 TPS로 지정된 고정 간격으로 보낸다.

옵션과 사용

고정 비율 컨트롤러는 레이트 컨트롤러 typefixed-rate 문자열로 설정함으로써 지정된다.

컨트롤러 옵션은 아래를 포함한다:

  • tps : 모든 워커들이 SUT로 트랜잭션을 누적 전송하는 비율

10 TPS를 가지는 고정 비율 컨트롤러는 아래 옵션으로 지정된다 :

{
  "type": "fixed-rate",
  "opts": {
      "tps" : 10
  }
}

Fixed feedback rate (고정 피드백 비율)


고정 피드백 비율 컨트롤러는 고정 비율의 확대 버전으로, 마찬가지로 인풋 트랜잭션을 고정 간격으로 전송한다. 종료되지 않은 트랜잭션이 각 워커의 정의된 종료되지 않은 트랜잭션 시간을 초과하면, 오랜 시간 휴면하여 일시적으로 인풋 트랜잭션 전송을 중지한다.

옵션과 사용

고정 피드백 비율 컨트롤러는 레이트 컨트롤러 typefixed-feedback-rate로 설정하여 지정가능하다.

컨트롤러 옵션은 아래를 포함한다:

  • tps : 모든 워커들이 SUT로 트랜잭션을 누적 전송하는 비율
  • transactionLoad : SUT의 최대 트랜잭션 부하로, 워커들이 트랜잭션 전송을 일시 중지하게 되는 부하값

100TPS와 SUT의 최대 트랜잭션 부하 100을 가진 고정 피드백 비율 컨트롤러는 아래 컨트롤러 옵션으로 지정된다 :

{
  "type": "fixed-feedback-rate",
  "opts": {
      "tps" : 100,
      "transactionLoad": 100
  }
}

Fixed load (고정 부하)


고정 부하 비율 컨트롤러는 타겟 부하(백로그 트랜잭션)에서 테스트를 구동하기 위한 컨트롤러다. 이 컨트롤러는 구동 TPS를 수정하여 시스템 내에서 정의된 트랜잭션 백로그를 유지하는 것을 목표로 한다. 결과는 트랜잭션 부하를 유지하면서 가질 수 있는 가능한 최대 TPS를 보여준다.

옵션과 사용

고정 부하 비율 컨트롤러는 레이트 컨트롤러 typefixed-load로 설정하여 지정가능하다.

컨트롤러 옵션은 아래를 포함한다:

  • startingTps : 모든 워커들에 의해 트랜잭션이 SUT에 누적 전송되는 초기 비율
  • transactionLoad : SUT에서 처리 중인 트랜잭션 수. 유지되어야 하는 값이다.

시작 TPS 100에서 5 트랜잭션 부하 유지를 목표로 하는 고정 부하 컨트롤러는 아래 컨트롤러 옵션으로 지정된다 :

{
  "type": "fixed-load",
  "opts": {
    "transactionLoad": 5,
    "startingTps": 100
  }
}

Maximum rate (최대 비율)


최대 비율 컨트롤러는 워커를 SUT 오버로딩 없이 달성가능한 최대 비율까지 구동하기 위한 컨트롤러이다. 이 컨트롤러는 워커의 구동 TPS를 최대화하는 것을 목표로 한다. 이는 구동 TPS를 증가시키고, TPS 감소가 목격되면 다시 뒤로 물러는 방법으로 진행된다. 여기서 TPS 감소는 시스템 오버로드를 가리킨다.

여기서 얻어지는 TPS는 txUpdate 사이클 사이에서 평가된다. 이는 그 시점이 TPS 결과가 사용가능해지는 시점이기 때문이다. 컨트롤러 안정성을 강화시키기 위해 TPS 비율 안정을 보장하는 최소 샘플 간격이 고려되어야 한다.

이 컨트롤러의 동작은 역치에 도달할 때 까지 각 워커의 달성가능한 최대 비율까지 천천히 증가함에 주의해라. 이는 라운드 평균 결과를 왜곡할 수 있는 유의미한 워밍업 단계가 있다는 뜻이다. Prometheus 쿼리나 Grafana 시각화를 사용해 달성가능한 결과를 분석하는 것이 추천된다.

옵션과 사용

최대 비율 컨트롤러는 레이트 컨트롤러 typemaximum-rate로 설정하여 지정가능하다.

컨트롤러 옵션은 아래를 포함한다:

  • tps : 시작 TPS
  • step : 각 간격에서 증가하는 TPS. "물러서기" 에서 이 스텝 사이즈는 TPS 증가를 다시 시도하기 전에 자동으로 축소된다.
  • sampleInterval : 달성가능한 TPS 비율 안정을 보장하기 위한 스텝 간 최소 간격
  • includeFailed : 컨트롤러 내 달성가능한 TPS 분석이 실패한 트랜잭션을 포함하는지를 가리키는 불리언 플래그(기본값 true)

스타팅 TPS 100, TPS 스텝 사이즈 5, 최소 샘플 간격 20초를 가진 최대 비율 컨트롤러는 아래 컨트롤러 옵션으로 지정된다 :

{
  "type": "maximum-rate",
  "opts": {
    "tps": 100,
    "step": 5,
    "sampleInterval": 20,
    "includeFailed": true
  }
}

Linear rate (선형 비율)


시스템 성능 한계 탐색은 대개 부하 강도를 증가시키며 여러 번 측정을 실시함으로써 이루어진다. 하지만 이 방법으로 시스템의 티핑 토인트를 찾는 것은 쉽지 않고, 이 방법은 좀 더 시행착오 방식에 가깝다.

선형 비율 컨트롤러는 시작 및 종료 TPS 값 사이에서 점진적으로 (선형적으로) TPS 비율을 변화시킬 수 있다. 이는 증가하는 방식과 감소하는 방식 모두에서 가능하다. 이것은 시스템 성능에 영향을 미치는 워크로드 비율을 더 쉽게 찾을 수 있게 해 준다.

선형 비율 컨트롤러는 기간-기반 및 트랜잭션 수-기반 라운드 둘 다에서 사용할 수 있다.

옵션과 사용

선형 비율 컨트롤러는 레이트 컨트롤러 typelinear-rate로 설정하여 지정가능하다.

컨트롤러 옵션은 아래를 포함한다:

  • startingTps : 라운드 시작 시점에 모든 워커가 SUT에 누적 전송하는 트랜잭션 비율
  • finishingTps : 라운드 종료 시점에 모든 워커가 SUT에 누적 전송하는 트랜잭션 비율

아래 예시는 벤치마크 라운드 동안 트랜잭션 부하를 25TPS에서 75TPS까지 점진적으로 변화시키는 레이트 컨트롤러를 지정한다:

{
  "type": "linear-rate",
  "opts": {
    "startingTps": 25,
    "finishingTps": 75
    }
}

참고 : 고정 비율 컨트롤러와 유사하게, 이 컨트롤러는 사용가능한 워커 사이에서 워크로드(작업 부하)를 나눈다. 따라서 이 구성에서 지정되는 비율은 누적 비율이고, 각 워커에 대한 비율이 아니다. 워커 다섯을 이용해 위 구성을 사용하면 각 워커의 비율은 5TPS에서 시작해 15TPS에서 종료된다. 합산해서 [25~75] TPS 부하를 생성한다.

Composite rate (복합 비율)


캘리퍼의 벤치마크 라운드는 싱글 레이트 컨트롤러와 연관되어 있다. 하지만 싱글 레이트 컨트롤러는 고급(advanced) 워커 동작 모델링에 충분하지 않다. 더욱이, 이러한 동작에 대한 새로운 레이트 컨트롤러 구현은 번거롭고 오류가 발생하기 쉽다. 대부분의 경우 복잡한 워커 동작은 여러개의 간단한 단계로 나눌 수 있다.

따라서, 복합 비율 컨트롤러는 여러 "간단한" 비율 컨트롤러 구성을 한 라운드에서 가능하게 한다. 이는 기존 레이트 컨트롤러 구현의 재사용을 촉진한다. 복합 비율 컨트롤러에서는 지정된 가중치에 따라 자동적으로 주어진 컨트롤 간 전환이 이루어진다. (예시에서 구성 디테일을 살펴 보자).

옵션과 사용

복합 비율 컨트롤러는 레이트 컨트롤러 typecomposite-rate로 설정하여 지정가능하다.

컨트롤러 옵션은 아래를 포함한다:

  • weights : "숫자 같은" 값(숫자 또는 숫자 문자열)의 배열. rateControllers 프로퍼티에서 정의되는 레이트 컨트롤러들과 연관되어 그 가중치를 지정한다.

    가중치의 합은 1이 되지 않아도 된다. 이는 가중치가 단위(unit) 길이 벡터로 표준화되기 때문이다. 따라서 주어진 구성에 대해 가장 직관적인 방식으로 가중치를 지정할 수 있다. 즉, 가중치는 지속 시간, 트랜잭션 수, 또는 비율에 대응될 수 있다.

    위 예시에서 가중치는 비율(2:1:2)에 대응되었다. 가중치의 정확한 의미는 벤치마크 라운드가 지속기간-기반(duration-based)인지 트랜잭션 수-기반(transaction number-based)인지에 따라 결정된다. 위 컨트롤러 정의가 지속 시간 5분인 라운드에 사용된다면, 첫 2분간은 트랜잭션이 100TPS로 제출되고, 다음 1분간 300 TPS로 제출되었다가 마지막 2분 간은 200TPS로 제출될 것이다.

    이 배열에서 가중치 0 또한 허용된다. 하나 이상의 컨트롤러 가중치를 0으로 설정하는 것은 구성 파일에서 실제로 컨트롤러를 제거하지 않고 컨트롤러를 제거/사용 불가로 만드는 편리한 방법이다.

  • rateControllers : 임시 레이트 컨트롤러 사양 배열. 구성 방법은 개별 레이트 컨트롤러 문서를 확인해야 한다. 지정된 레이트 컨트롤러 수는 지정된 가중치 수와 같아야 한다.

  • logChange : 지정된 레이트 컨트롤러 간 전환이 로깅되는지를 가리키는 boolean 값.

아래 예시는 트랜잭션 제출 비율로 다양한 진폭을 가진 구형파 함수를 정의한 것이다. 이것은 서로 다른 TPS 설정을 가진 고정 비율 컨트롤러 간 전환으로 구성되어 설정이 쉽다:

{
  "type": "composite-rate",
  "opts": {
    "weights": [2, 1, 2],
    "rateControllers": [
      {
        "type": "fixed-rate",
        "opts": {"tps" : 100}
      },
      {
        "type": "fixed-rate",
        "opts": {"tps" : 300}
      },
      {
        "type": "fixed-rate",
        "opts": {"tps" : 200}
      }
    ],  
    "logChange": true
  }
}

주의! 복합 비율 컨트롤러는 지정된 "하위 컨트롤러들"을 거의 투영한다. 이는 해당 컨트롤러들이 "가상화된" 라운드에 놓이기 때문에 가능하다. 이는 컨트롤러들에게 다음 사항에 대해 "거짓말" 한다는 것을 뜻한다:

  • (지속 시간 기반 라운드에서) 라운드 지속 시간
  • (트랜잭션 수 기반 라운드에서) 제출되는 총 트랜잭션 수
  • 라운드 시작 시간
  • 제출되는 다음 트랜잭션의 인덱스.
    가까운 시간 내에 완료된 트랜잭션의 결과는 하위 컨트롤러에 있는 그대로 전파되므로, 새로 활성화된 하위 컨트롤러의 첫 몇 호출에 대해서는 가상화 라운드에 속하지 않은 최근 결과를 수신할 수 있다.

기억에 의존하지 않는, 즉 컨트롤 로직이 전체 라운드 프로퍼티나 과거 트랜잭션 결과에 의존하지 않는 컨트롤러에는 가상화가 영향을 미치지 않는다. 하지만, 다른 컨트롤러들은 가상화 접근 방식 때문에 이상한(아마도 일시적인) 동작을 보일 수 있다. 예를 들어, PID 컨트롤러의 로직은 트랜잭션 백로그에 의존한다.

Zero rate (영비율)


이 컨트롤러는 라운드 지속 기간 동안 워크로드 생성을 멈춘다.

옵션과 사용

한 라운드에 이 컨트롤러를 단독으로 사용하는 것은 의미가 없다. 하지만 복합 비율 컨트롤러 내부에 블록을 생성하기 위해 사용할 수 있다. 영비율 컨트롤러는 오직 지속기간-기반 라운드에서만 사용될 수 있다!

{
  "type": "composite-rate",
  "opts": {
    "weights": [30, 10, 10, 30],
    "rateControllers": [
      {
        "type": "fixed-rate",
        "opts": {"tps" : 100}
      },
      {
        "type": "fixed-rate",
        "opts": {"tps" : 500}
      },
      {
        "type": "zero-rate",
        "opts": { }
      },
      {
        "type": "fixed-rate",
        "opts": {"tps" : 100}
      }
    ],  
    "logChange": true
  }
}

위 예시가 지속기간 80초를 가진 라운드 정의에 사용된다고 가정해 보자(직관적인 가중치 지정에 주의하자). 이 케이스는 최초 30초의 일반 워크로드 이후 10초 간 집약적인 워크로드가 따라오고, 이후 10초간의 쿨다운 기간이 있는 식으로 이어진다.

이 컨트롤러는 레이트 컨트롤러 typezero-rate로 설정하여 지정가능하고, 추가 구성을 요구하지 않는다.

Record rate (기록 비율)


이 레이트 컨트롤러는 다른 (임시) 컨트롤러 주변에서 데코레이터 역할을 한다. 이것의 목적은 각 트랜잭션이 제출되는, 즉 트랜잭션이 "하위 컨트롤러"에 의해 "활성화(enabled)"되는, 시간을 (라운드 시작을 기준으로) 기록하는 것이다.

아래 예시는 하위 고정 비율 컨트롤러가 트랜잭션을 활성화하는 시간을 기록한다(자세한 내용은 예시 아래의 가능한 옵션을 살펴보자):

{
  "type": "record-rate",
  "opts": {
    "rateController": {
      "type": "fixed-rate",
      "opts": {"tps" : 100}
    },
    "pathTemplate": "../tx_records_client<C>_round<R>.txt",
    "outputFormat": "TEXT",
    "logEnd": true
  }
}

이 컨트롤러는 레이트 컨트롤러 typerecord-rate로 설정하여 지정가능하고, 가능한 옵션들 (opts 프로퍼티)는 다음과 같다:

  • rateController : 임시 레이트 컨트롤러 사양.

  • pathTemplate : 기록된 시간이 저장될 파일 경로 템플릿. 이 경로는 절대 경로 또는 루트 캘리퍼 디렉토리에 대한 상대경로가 될 수 있다.

    이 템플릿은 특별한 "variables/placeholders"를 가지고 있어야 한다. 이것들은 특정 환경 프로퍼티들을 참조할 수 있다(아래 비고를 보자). 사용가능한 placeholders는 다음과 같다:

    • <C> : 레이트 컨트롤러를 사용하는 현재 워커의 1-based index를 위한 placeholder
    • <R> : 레이트 컨트롤러를 사용하는 현재 라운드의 1-based index를 위한 placeholder
  • outputFormat : 선택사항(optional). 기록이 저장될 포맷을 결정한다. 기본 값은 "TEXT"이다. 현재 지원하는 포맷들은 다음과 같다:

    • "TEXT" : 각 저장된 타이밍이 분리된 줄의 텍스트로 저장된다.
    • "BIN_BE" : Big Endian encoding 바이너리 포맷.
    • "BIN_LE" : Little Endian encoding 바이너리 포맷.
  • logEnd : 선택사항. 로그가 파일에 기록되는지 여부를 가리킨다. 기본 값은 false이다.

템플릿 플레이스홀더: 캘리퍼는 동일한 동작을 하는 여러 라운드와 여러 워커를 정의하는 간결한 방법을 제공하므로, 워커와 라운드 기록을 구분하는 것이 중요하다. 따라서, 출력 파일 경로는 라운드와 워커 인덱스를 위한 플레이스홀더를 포함할 수 있다 이것은 각 라운드의 각 워커에서 자동으로 resolve된다. 그렇지 않으면, 각 워커가 동일한 파일을 작성해 타이밍과 트랜잭션 ID 간 심각한 충돌이 일어난다.

텍스트 포맷: 레이트 컨트롤러는 아래 포맷으로 기록을 저장한다(일정한 10TPS 비율을 가정하고 실제 타이밍 노이즈는 무시한다). 로우 ii번째 트랜잭션과 대응된다:

100
200
300
...

바이너리 포맷: 바이너리 형식은 X 개의 기록을 X+1 UInt32 숫자로 인코딩한다 (숫자 하나는 배열 길이에 대한 것이고, 나머지는 배열 엘리먼트에 대한 것이다). Little Endian 또는 Big Endian 인코딩이 가능하다:

Offset: |0      |4      |8      |12      |16      |...     
Data:   |length |1st    |2nd    |3rd     |4th     |...   

Replay rate (반복 비율)


좋은 벤치마크의 가장 중요한 측면 중 하나는 반복성이다. 즉, 필요할 때 마다 결정적인 방식으로 재실행할 수 있어야 한다. 그러나, 어떤 벤치마크들은 워크로드(예: 유저의 동작)을 확룔적 분포 함수로 정의한다. 이것은 실용적인 관점에서 두 가지 문제를 가진다:
1. 반복성: 주어진 확률분포에 대한 랜덤 샘플링은 벤치마크 재 실행 간 다를 수 있다, 이것은 플랫폼 간 비교를 믿기 어렵게 만든다.
2. 효율성: 복잡한 확률 분포 샘플링은 추가 런타임 오버헤드를 발생시킨다. 이것은 부하 비율을 제한하여, 원래 지정한 워크로드에 대한 부하를 일으킬 수 있다.

이 레이트 컨트롤러는 오프라인으로 생성된 고정 트랜잭션 로드 프로파일을 재생하여 위와 같은 문제를 완화시키려는 목적이 있다. 이 방법으로 프로파일은 벤치마크 실행 외부에서 한 번만 생성되고, 최소 오버헤드 제약을 가진 동일한 타이밍으로 언제든지 재생될 수 있다.

이 컨트롤러의 간단한 사용 방법은 레코드 컨트롤러로 생성된 트랜잭션 기록을 재생하는 것이다. 하지만 잘 구성된 추적 파일이 이 컨트롤러의 유일한 요구 사항이므로, 모든 툴이나 메서드를 트랜잭션 로드 프로파일 생성에 사용할 수 있다.

아래 예시는 동일 워커-의존적 워크로드 프로파일을 재생하는 레이트 컨트롤러를 지정한다(자세한 사항은 예시 아래에 있는 가능한 옵션들을 보자):

{
  "type": "replay-rate",
  "opts": {
    "pathTemplate": "../tx_records_client<C>.txt",
    "inputFormat": "TEXT",
    "logWarnings": true,
    "defaultSleepTime": 50
    }
}

이 컨트롤러는 레이트 컨트롤러 typereplay-rate로 설정하여 지정가능하고, 가능한 옵션들 (opts 프로퍼티)는 다음과 같다:

  • pathTemplate : 트랜잭션 타이밍이 재생될 파일 경로 템플릿. 이 경로는 절대 경로 또는 루트 캘리퍼 디렉토리에 대한 상대경로가 될 수 있다.

    이 템플릿은 특별한 "variables/placeholders"를 가지고 있어야 한다. 이것들은 특정 환경 프로퍼티들을 참조할 수 있다. 사용가능한 placeholders는 다음과 같다:

    • <C> : 레이트 컨트롤러를 사용하는 현재 워커의 1-based index를 위한 placeholder
    • <R> : 레이트 컨트롤러를 사용하는 현재 라운드의 1-based index를 위한 placeholder
  • inputFormat : 선택사항(optional). 트랜잭션 타이밍이 저장될 포맷을 결정한다. 기본 값은 "TEXT"이다. 현재 지원하는 포맷들은 다음과 같다:

    • "TEXT" : 각 저장된 타이밍이 분리된 줄의 텍스트로 저장된다.
    • "BIN_BE" : Big Endian encoding 바이너리 포맷.
    • "BIN_LE" : Little Endian encoding 바이너리 포맷.
  • logWarnings : 선택사항. 재생할 기록이 더 없을 때 로그를 남기는지, 그래서 defaultSleepTime가 연속된 트랜잭션 사이에서 사용되는지를 가리킨다. 기본값은 false이다.

  • defaultSleepTime : 선택사항. 벤치마크 실행이 지정된 레코딩보다 길 때 트랜잭션 간 sleep 시간을 결정한다. 기본값은 20ms이다.

기록에 대하여:
지속기간-기반 벤치마크 실행을 사용할 때 특별히 주의해야 한다. 기록에서 지정한 것보다 많은 트랜잭션을 발행할 가능성이 있기 때문이다. 이런 케이스를 위한 안전 조치는 defaultSleepTime 옵션이다. 이것은 오직 결과에 대한 추가 성능 분석 수행 이전에 제거할 수 있는 적은 수의 트랜잭션에만 영향을 끼치는 실행의 마지막 몇 순간에만 일어나야 한다.

추천되는 접근 방식은 트랜잭션 수-기반 라운드 구성이다. 반복해야 하는 트랜잭션 수가 미리 알려져있기 때문이다. 워커의 수가 워커에 의해 제출되는 실제 트랜잭션 수에 영향을 준다는 점에 주의하자.

커스텀 컨트롤러 추가


캘리퍼의 내장 컨트롤러가 아닌 레이트 컨트롤러를 사용하는 것도 가능하다. 테스트 구성 파일에서 레이트 컨트롤러를 지정할 때 (아키텍처 문서를 보자) typeopts 속성을 지정해주어야 한다.

type 속성을 설정해 아래 기준을 만족하는 커스텀 js 파일을 가리키도록 할 수 있다:

  1. 파일 또는 모듈이 아래 파라미터들을 가지는 createRateController 펑션을 export한다:

    1. TestMessage 파라미터 : 구성 파일의 opts attribute set의 object representation이다. 레이트 컨트롤러의 커스텀 설정들을 표함한다.

    2. TransactionStatisticsCollector object : 현재 워커 트랜잭션 통계에 대한 레이트 컨트롤러 액세스를 제공하는 객체

    3. number 타입인 workerIndex 파라미터: 레이트 컨트롤러를 사용하는 워커 프로세스의 0-based index.

      함수는 반드시 아래 기준을 만족하는 객체를 반환해야 한다(즉, 해당 레이트 컨트롤러 인스턴스를 리턴해야 한다.)

  2. createRateController에 의해 리턴되는 객체는 반드시 /packages/caliper-core/lib/rate-control/rateInterface.js인터페이스를 구현해야 한다. 즉, 반드시 아래 async function을 제공해야 한다.

    1. applyRateControl : 원하는 시간 동안 (비동기 방식으로) 실행을 "blocking" 하여 실제 레이트 컨트롤을 수행한다.
    2. end : 라운드 종료 시 획득한 자원을 제거한다.

아래 예시는 컨트롤 역할을 수행하지 않는 레이트 컨트롤의 완전한 구현이다. 즉, 프로그램 실행이 허용하는 한 빠른 트랜잭션 제출을 허용한다 (경고. 많은 워커 프로세스로 실행되는 이 구현은 백엔드 네트워크에 쉽게 오버로드를 줄 수 있으므로 주의해서 사용해야 한다).

/*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

'use strict';

const RateInterface = require('path-to-caliper/caliper-core/lib/rate-control/rateInterface.js');

/**
 * Rate controller for allowing uninterrupted workload generation.
 *
 * @property {object} options The user-supplied options for the controller. Empty.
 */
class MyRateController extends RateInterface{
    /**
     * Initializes the rate controller instance.
     * @param {TestMessage} testMessage The testMessage passed for the round execution
     * @param {TransactionStatisticsCollector} stats The TX stats collector instance.
     * @param {number} workerIndex The 0-based index of the worker node.
     * @param {number} roundIndex The 0-based index of the current round.
     * @param {number} numberOfWorkers The total number of worker nodes.
     * @param {object} roundConfig The round configuration object.
     */
    constructor(testMessage, stats, workerIndex) {
        super(testMessage, stats, workerIndex);
    }

    /**
     * Doesn't perform any rate control.
     * @async
     */
    async applyRateControl() {
        // no sleeping is needed, allow the transaction invocation immediately
    }

    /**
     * Notify the rate controller about the end of the round.
     * @async
     */
    async end() { 
        // nothing to dispose of
    }
}

/**
 * Factory for creating a new rate controller instance.
 * @param {TestMessage} testMessage start test message
 * @param {TransactionStatisticsCollector} stats The TX stats collector instance.
 * @param {number} workerIndex The 0-based index of the worker node.
 *
 * @return {RateInterface} The new rate controller instance.
 */
function createRateController(testMessage, stats, workerIndex) {
    return new MyRate(testMessage, stats, workerIndex);
}

module.exports.createRateController = createRateController;

이 구현을 캘리퍼 디렉토리 옆에 있는 myRateController.js 파일에 저장한다고 가정해 보자 (즉, 디렉토리와 파일이 같은 레벨에 있다). 이 테스트 구성 파일에서 아래 방식과 같이 레이트 컨트롤러를 (구성 계층에서 요구되는 위치로) 설정할 수 있다.

rateControl:
  # relative path from the Caliper directory
- type: ../myRateController.js
  # empty options
  opts: 

라이선스

The Caliper codebase is released under the Apache 2.0 license. Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at http://creativecommons.org/licenses/by/4.0/.

0개의 댓글