Bencher로 CI에서 벤치마크를 추적하는 방법

대부분의 벤치마크 결과는 일시적입니다. 터미널의 스크롤백 한계에 도달하면 사라집니다. 일부 벤치마크 하니스는 결과를 캐시할 수 있게 하지만, 대부분은 로컬에서만 가능합니다. Bencher는 로컬 및 CI 실행 모두에서 벤치마크를 추적하고 결과를 비교할 수 있게 해주며, 여전히 좋아하는 벤치마크 하니스를 사용할 수 있습니다.

지속적 벤치마킹, 즉 CI에서의 벤치마킹 시 벤치마크 결과를 비교하는 세 가지 인기 있는 방법이 있습니다:

• 통계적 지속적 벤치마킹
  1. 벤치마크 결과를 시간에 따라 추적하여 기준선 생성
  2. 이 기준선을 통계적 기준과 함께 사용하여 통계적 경계선 생성
  3. 새로운 결과를 이 통계적 경계선과 비교하여 성능 퇴행 감지
• 상대적 지속적 벤치마킹
  1. 현재 기준선 코드에 대해 벤치마크 실행
  2. 코드의 새로운 버전으로 전환
  3. 백분율 기준을 사용하여 기준선 코드의 경계 생성
  4. 코드의 새로운 버전에 대해 벤치마크 실행
  5. 코드의 새로운 버전 결과를 기준선 코드 결과와 비교하여 성능 퇴행 감지
• 변화점 탐지
  1. 가끔 코드의 새로운 버전에 대해 벤치마크 실행
  2. 변화점 탐지 알고리즘을 사용하여 성능 퇴행 감지
  3. 성능 퇴행을 유발한 커밋 찾기 위해 이분법적 분석 수행

통계적 지속적 벤치마킹

빠른 시작 및 Docker 자체 호스팅 튜토리얼에서 중단했던 곳에서 시작하여, Save Walter White 프로젝트에 통계적인 지속적 벤치마킹을 추가하겠습니다.

🐰 계속하기 전에 API 토큰을 생성하고 BENCHER_API_TOKEN 환경 변수로 설정했는지 확인하세요!

이제 CI에서 벤치마크를 실행할 준비가 되었습니다. 모든 CI 환경은 약간씩 다르기 때문에, 다음 예제는 실제적이기보다는 설명을 위한 것입니다. 더 구체적인 예제는 GitHub Actions에서의 지속적 벤치마킹 및 GitLab CI/CD에서의 지속적 벤치마킹을 참조하세요.

먼저, 맡기 전에 main 브랜치에 대한 역사적 기준선을 만들어 유지하기 위해 CI에서 모든 변경 사항을 벤치마킹해야 합니다:

bencher run \
--project save-walter-white-1234abcd \
--branch main \
--testbed ci-runner \
--threshold-measure latency \
--threshold-test t_test \
--threshold-max-sample-size 64 \
--threshold-upper-boundary 0.99 \
--thresholds-reset \
--err \
--adapter json \
bencher mock

1. main 브랜치 벤치마크를 실행하려면 bencher run CLI 서브커맨드를 사용합니다. bencher run CLI 서브커맨드에 대한 전체 개요를 참조하세요. (예: bencher run)
2. --project 옵션을 프로젝트 슬러그로 설정합니다. 더 자세한 내용은 --project 문서를 참조하세요. (예: --project save-walter-white-1234abcd)
3. --branch 옵션을 기본 브랜치 이름으로 설정합니다. 전체 개요는 --branch 문서를 참조하세요. (예: --branch main)
4. --testbed 옵션을 CI 러너 테스트베드 이름으로 설정합니다. 더 자세한 내용은 --testbed 문서를 참조하세요. (예: --testbed ci-runner)
5. main 브랜치, ci-runner 테스트베드 및 latency 측정을 위한 임계값을 설정합니다:
   1. --threshold-measure 옵션을 bencher mock에 의해 생성되는 기본 latency 측정으로 설정합니다. 자세한 내용은 --threshold-measure 문서를 참조하세요. (예: --threshold-measure latency)
   2. --threshold-test 옵션을 스튜던트 t-테스트 (t_test)로 설정합니다. 전체 개요는 --threshold-test 문서를 참조하세요. (예: --threshold-test t_test)
   3. --threshold-max-sample-size 옵션을 64의 최대 샘플 크기로 설정합니다. 더 자세한 내용은 --threshold-max-sample-size 문서를 참조하세요. (예: --threshold-max-sample-size 64)
   4. --threshold-upper-boundary 옵션을 0.99의 상한으로 설정합니다. 더 자세한 내용은 --threshold-upper-boundary 문서를 참조하세요. (예: --threshold-upper-boundary 0.99)
   5. 지정된 임계값만 활성화되도록 --thresholds-reset 플래그를 설정합니다. 전체 개요는 --thresholds-reset 문서를 참조하세요. (예: --thresholds-reset)
6. 경보가 생성되면 명령을 실패하게 하려면 --err 플래그를 설정합니다. 전체 개요는 --err 문서를 참조하세요. (예: --err)
7. bencher mock에 의해 생성된 벤처 메트릭 형식 JSON (json)을 --adapter 옵션으로 설정합니다. 벤치마크 하네스 어댑터에 대한 전체 개요는 어댑터 JSON를 참조하세요. (예: --adapter json)
8. 벤치마크 명령 인수를 지정합니다. 벤치마크 명령에 대한 전체 개요는 명령 인수를 참조하세요. (예: bencher mock)

처음 이 명령을 CI에서 실행하면, main 브랜치가 아직 존재하지 않을 경우 생성됩니다. 새로운 main은 시작점이나 기존 데이터가 없습니다. main 브랜치, ci-runner 테스트베드 및 latency 측정을 위한 임계값이 생성됩니다. 후속 실행에서는 새로운 데이터가 main 브랜치에 추가됩니다. 지정된 임계값은 성능 퇴보를 감지하는 데 사용됩니다.

이제, 우리는 CI에서 성능 퇴보를 잡을 준비를 마쳤습니다. 이는 CI에서 feature-branch라는 적절한 이름의 새 기능 브랜치의 성능을 추적하는 방법입니다:

bencher run \
--project save-walter-white-1234abcd \
--branch feature-branch \
--start-point main \
--start-point-hash 32aea434d751648726097ed3ac760b57107edd8b \
--start-point-clone-thresholds \
--start-point-reset \
--testbed ci-runner \
--err \
--adapter json \
bencher mock

1. feature-branch 브랜치 벤치마크를 실행하려면 bencher run CLI 서브커맨드를 사용합니다. bencher run CLI 서브커맨드에 대한 전체 개요를 참조하세요. (예: bencher run)
2. --project 옵션을 프로젝트 슬러그로 설정합니다. 더 자세한 내용은 --project 문서를 참조하세요. (예: --project save-walter-white-1234abcd)
3. --branch 옵션을 기능 브랜치 이름으로 설정합니다. 전체 개요는 --branch 문서를 참조하세요. (예: --branch feature-branch)
4. feature-branch 브랜치를 위한 시작점을 설정합니다:
   1. --start-point 옵션을 기능 브랜치 시작점으로 설정합니다. 전체 개요는 --start-point 문서를 참조하세요. (예: --start-point main)
   2. --start-point-hash 옵션을 기능 브랜치 시작점 git 해시로 설정합니다. 전체 개요는 --start-point-hash 문서를 참조하세요. (예: --start-point-hash 32ae...dd8b)
   3. --start-point-clone-thresholds 플래그를 설정하여 시작점의 임계값을 복제합니다. 전체 개요는 --start-point-clone-thresholds 문서를 참조하세요. (예: --start-point-clone-thresholds)
   4. 브랜치를 항상 시작점으로 재설정하도록 --start-point-reset 플래그를 설정합니다. 이렇게 하면 벤치마크 데이터 드리프트를 방지할 수 있습니다. 전체 개요는 --start-point-reset 문서를 참조하세요. (예: --start-point-reset)
5. --testbed 옵션을 테스트베드 이름으로 설정합니다. 더 자세한 내용은 --tested 문서를 참조하세요. (예: --testbed ci-runner)
6. 경보가 생성되면 명령을 실패하게 하려면 --err 플래그를 설정합니다. 전체 개요는 --err 문서를 참조하세요. (예: --err)
7. bencher mock에 의해 생성된 벤처 메트릭 형식 JSON (json)을 --adapter 옵션으로 설정합니다. 벤치마크 하네스 어댑터에 대한 전체 개요는 어댑터 JSON를 참조하세요. (예: --adapter json)
8. 벤치마크 명령 인수를 지정합니다. 벤치마크 명령에 대한 전체 개요는 명령 인수를 참조하세요. (예: bencher mock)

처음 이 명령을 CI에서 실행하면, 벤처는 아직 존재하지 않는 feature-branch 브랜치를 생성합니다. 새 feature-branch는 해시 32aea434d751648726097ed3ac760b57107edd8b에 있는 main 브랜치를 시작점으로 사용합니다. 이는 feature-branch가 bencher mock의 결과와 비교할 수 있도록 main 브랜치의 모든 데이터 및 임계값의 복사본을 갖게 된다는 것을 의미합니다. 모든 후속 실행 시, 벤처는 feature-branch 브랜치를 시작점으로 재설정하고, main 브랜치 데이터 및 임계값을 사용하여 성능 퇴보를 감지할 것입니다.

상대적 지속적 벤치마킹

빠른 시작 및 자체 호스팅 Docker 튜토리얼에서 이어서, Save Walter White 프로젝트에 상대적 지속적 벤치마킹을 추가하겠습니다.

🐰 계속하기 전에 API 토큰을 생성하고 이를 BENCHER_API_TOKEN 환경 변수로 설정하십시오!

상대적 지속적 벤치마킹은 코드의 두 버전을 나란히 비교하여 실행합니다. 이는 실행 간 사용할 수 있는 리소스가 매우 불규칙할 수 있는 시끄러운 CI/CD 환경에서 유용할 수 있습니다. 이 예제에서는 main 브랜치에서 실행한 결과와 적절히 명명된 feature-branch라는 기능 브랜치에서 실행한 결과를 비교할 것입니다. 모든 CI 환경이 약간씩 다르기 때문에, 다음 예제는 실용적이라기보다는 설명을 목적으로 합니다. 더 구체적인 예제를 보려면 GitHub Actions에서의 지속적 벤치마킹과 GitLab CI/CD에서의 지속적 벤치마킹을 참조하세요.

먼저, CI에서 git으로 main 브랜치를 체크아웃해야 합니다:

git checkout main

그런 다음, CI에서 main 브랜치에 대해 벤치마크를 실행해야 합니다:

bencher run \
--project save-walter-white-1234abcd \
--branch main \
--start-point-reset \
--testbed ci-runner \
--adapter json \
bencher mock

1. bencher run CLI 하위 명령어를 사용하여 main 브랜치 벤치마크를 실행하세요. bencher run CLI 하위 명령어에 대한 전체 개요를 참조하세요. (예: bencher run)
2. --project 옵션을 프로젝트 슬러그로 설정합니다. 자세한 내용은 --project 문서를 참조하세요. (예: --project save-walter-white-1234abcd)
3. --branch 옵션을 기본 브랜치 이름으로 설정합니다. --branch 문서에 대한 전체 개요를 참조하세요. (예: --branch main)
4. --start-point-reset 플래그를 설정하여 항상 기본 브랜치를 재설정합니다. 이를 통해 모든 벤치마크 데이터가 현재 CI 러너에서 나온 것임을 보장합니다. --start-point-reset 문서에 대한 전체 개요를 참조하세요. (예: --start-point-reset)
5. --testbed 옵션을 CI 러너 테스트베드 이름으로 설정합니다. 자세한 내용은 --testbed 문서를 참조하세요. (예: --testbed ci-runner)
6. bencher mock으로 생성된 Bencher Metric Format JSON (json)을 --adapter 옵션으로 설정합니다. 벤치마크 하네스 어댑터에 대한 전체 개요는 어댑터 json을 참조하세요. (예: --adapter json)
7. 벤치마크 명령의 인수를 지정합니다. 벤치마크 명령에 대한 전체 개요는 명령 인수를 참조하세요. (예: bencher mock)

이 명령이 CI에서 처음 실행될 때, 아직 존재하지 않으므로 main Branch가 생성됩니다. 새로운 main에는 시작 지점, 기존 데이터 또는 임계값이 없습니다. 이후의 실행에서는 이전 main 머리가 대체되고 시작 지점, 기존 데이터 또는 임계값 없이 새로운 main 머리가 생성됩니다.

다음으로, CI에서 git으로 feature-branch 브랜치를 체크아웃해야 합니다:

git checkout feature-branch

마지막으로 CI에서 feature-branch 벤치마크를 실행할 준비가 되었습니다:

bencher run \
--project save-walter-white-1234abcd \
--branch feature-branch \
--start-point main \
--start-point-reset \
--testbed ci-runner \
--threshold-measure latency \
--threshold-test percentage \
--threshold-upper-boundary 0.25 \
--thresholds-reset \
--err \
--adapter json \
bencher mock

1. bencher run CLI 하위 명령어를 사용하여 feature-branch 벤치마크를 실행하세요. bencher run CLI 하위 명령어에 대한 전체 개요를 참조하세요. (예: bencher run)
2. --project 옵션을 프로젝트 슬러그로 설정합니다. 자세한 내용은 --project 문서를 참조하세요. (예: --project save-walter-white-1234abcd)
3. --branch 옵션을 기능 브랜치 이름으로 설정합니다. --branch 문서에 대한 전체 개요를 참조하세요. (예: --branch feature-branch)
4. feature-branch 브랜치 시작점을 설정하세요:
   1. --start-point 옵션을 기능 브랜치 시작점으로 설정합니다. 자세한 내용은 --start-point 문서를 참조하세요. (예: --start-point main)
   2. 항상 브랜치를 시작점으로 재설정하려면 --start-point-reset 플래그를 설정합니다. 이는 최신 상대 벤치마크 결과만 사용합니다. 자세한 내용은 --start-point-reset 문서를 참조하세요. (예: --start-point-reset)
5. --testbed 옵션을 CI 러너 테스트베드 이름으로 설정합니다. 자세한 내용은 --testbed 문서를 참조하세요. (예: --testbed ci-runner)
6. feature-branch 브랜치, ci-runner 테스트베드 및 latency 측정 값을 위한 임계값을 설정하세요:
   1. 내장된 latency 측정 값을 bencher mock으로 --threshold-measure 옵션에 설정합니다. 자세한 내용은 --threshold-measure 문서를 참조하세요. (예: --threshold-measure latency)
   2. 기본 비율(percentage)로 --threshold-test 옵션을 설정합니다. 이에 대한 전체 개요는 --threshold-test 문서를 참조하세요. (예: --threshold-test percentage)
   3. --threshold-upper-boundary 옵션을 0.25의 상한값으로 설정합니다. 자세한 내용은 --threshold-upper-boundary 문서를 참조하세요. (예: --threshold-upper-boundary 0.25)
   4. 지정된 임계값만 활성 상태가 되도록 --thresholds-reset 플래그를 설정합니다. 이에 대한 전체 개요는 --thresholds-reset 문서를 참조하세요. (예: --thresholds-reset)
7. 경고가 생성되면 명령이 실패하도록 --err 플래그를 설정합니다. 이에 대한 전체 개요는 --err 문서를 참조하세요. (예: --err)
8. --adapter 옵션으로 Bencher Metric Format JSON (json)을 bencher mock으로 생성합니다. 벤치마크 하네스 어댑터에 대한 전체 개요는 어댑터 json을 참조하세요. (예: --adapter json)
9. 벤치마크 명령의 인수를 지정합니다. 벤치마크 명령에 대한 전체 개요는 명령 인수를 참조하세요. (예: bencher mock)

이 명령이 CI에서 실행될 때마다, feature-branch의 결과를 main의 가장 최근 결과와 비교합니다. 지정된 임계값은 성능의 퇴보를 감지하는 데 사용됩니다.

Change Point Detection

Change Point Detection은 변화점 탐지 알고리즘을 사용하여 최근 결과의 큰 윈도우를 평가합니다. 이는 알고리즘이 이상치를 노이즈로 무시하고 허위 긍정을 줄일 수 있게 합니다. Change Point Detection은 지속적인 벤치마킹으로 간주되지만, CI에서 성능 회귀를 탐지할 수는 없습니다. 즉, 기능 브랜치가 병합되기 전에 성능 회귀를 탐지할 수 없습니다. 이는 때때로 “외부 검출”이라고도 불립니다.

예를 들어, bench_my_critical_path라는 벤치마크가 있고, 다음과 같은 과거 지연 시간이 있었습니다: 5 ms, 6 ms, 5 ms, 5ms, 7ms.

다음 벤치마크 결과가 11 ms라면, 통계적 지속 벤치마킹 임계값과 Change Point Detection 알고리즘이 이를 매우 다르게 해석할 것입니다. 임계값은 초과할 가능성이 높고 경고가 생성될 것입니다. 이 벤치마크 실행이 풀 리퀘스트와 연결되었다면, 이 경고로 인해 빌드가 실패로 설정될 가능성이 높습니다. 그러나, 변화점 알고리즘은 아직 아무 것도 하지 않을 것입니다. 다음 실행에서 5 ms로 다시 떨어진다면 경고를 생성하지 않을 것입니다. 반대로, 다음 실행 또는 두 번의 실행에서 10 ms 및 12 ms가 나왔다면, 그제서야 변화점 알고리즘이 경고를 발휘할 것입니다.

Bencher와 Change Point Detection을 사용하고 싶으신가요? 그렇다면 트래킹 문제에 코멘트를 남기거나 직접 문의하세요.

🐰 축하합니다! Bencher로 CI에서 벤치마크를 추적하는 방법을 배웠습니다! 🎉

GitHub Actions에 Bencher 추가하기 ➡

GitLab CI/CD에 Bencher 추가하기 ➡