에피소드 20: 워싱턴주 벨뷰에 위치한 존 첸 (2021년 4월)
이전 에피소드
속도는 Chrome의 4가지 핵심 원칙 중 하나입니다. 벤치마크를 추가하면 손쉽게 성능 회귀를 방지하고 시간 경과에 따라 성능을 개선할 수 있습니다. 좋은 벤치마크는 반복 주기가 빠르고 UMA보다 훨씬 일찍 성능 회귀를 포착할 수 있으며 새 기능의 성능을 측정하는 데 유용합니다.
벤치마크는 실험실에서 정기적으로 실행됩니다. 회귀가 발견되면 bisect가 자동으로 원인 CL을 찾아 CL 소유자에게 버그를 할당합니다.
Chrome 벤치마크는 웹페이지 상호작용 (스토리라고 함) 시퀀스를 성능 측정과 결합합니다. 유사한 사례는 벤치마크 하네스로 그룹화됩니다. 일반적으로 새 벤치마크는 기존 하네스 중 하나에 적합합니다.
- 시스템 상태
- 로드 중
- 메모리
- 렌더링
- 전력
- 시작
- V8 런타임
- 미디어
- WebRTC
- 보도자료
- 깜빡임 성능
원격 분석 프레임워크는 녹화된 스토리를 재생하여 Chrome 활동을 기록하는 트레이스를 수집하는 동시에 Chrome과의 사용자 상호작용을 시뮬레이션합니다. 스토리가 끝나면 프레임워크는 다양한 성능 측정항목을 실행하여 트레이스를 분석하고 성능 결과를 계산합니다.
기존 하네스 중 하나에 포함된 기존 측정항목을 사용하여 새 스토리를 추가하는 방식으로 Chrome의 새로운 성능 테스트 사례 대부분을 다룰 수 있습니다. 추가 트레이스를 수집하고 기존 벤치마크에 측정항목을 추가하거나 브라우저에 추가 플래그를 전달할 수도 있습니다.
다른 하네스에 맞지 않는 일회성 케이스에 Blink Perf를 사용합니다. Blink Perf에서는 일회성 페이지에서 트레이스 이벤트를 측정할 수 있습니다.
벤치마크 스토리를 단순하게 유지하고 시나리오를 완료하는 데 필요한 최소한의 상호작용만 포함하세요. 테스트 사례가 복잡하면 자동화하기가 어렵거나 불안정할 수 있습니다.
가장 중요한 사용 사례를 포함하는 가장 작은 수로 테스트를 제한합니다. 벤치마킹 인프라는 유지보수 비용이 많이 듭니다. 지원되는 하드웨어 목록은 Chrome 속도 기기를 참고하세요.
실적을 측정하는 방법에는 여러 가지가 있습니다. 원격 분석 기반 벤치마크는 외부 프로세스에서 Chrome을 제어하므로 항상 필요한 제어 수준을 제공하는 것은 아닙니다. 대신 gtest 기반 벤치마크를 사용하면 테스트 코드가 Chrome 코드와 동일한 프로세스를 공유할 수 있습니다. 실험실이 아닌 사용자 기기에서 성능을 측정하는 데 UMA를 사용하는 등의 다른 성능 도구도 고려해 볼 수 있습니다.
Chrome 벤치마킹에 대해 자세히 알고 싶으신가요? telemetry@chromium.org에 문의하세요.