이 페이지에서는 Bazel을 반복적으로 실행할 때 Bazel의 빌드 성능을 최적화하는 방법을 설명합니다.
Bazel의 런타임 상태
Bazel 호출에는 여러 상호작용하는 부분이 포함됩니다.
bazel명령줄 인터페이스 (CLI)는 사용자 대상 프런트엔드 도구이며 사용자로부터 명령어를 수신합니다.CLI 도구는 고유한 각 출력 기반에 대해 Bazel 서버 를 시작합니다. Bazel 서버는 일반적으로 지속되지만 리소스 낭비를 방지하기 위해 유휴 시간이 지나면 종료됩니다.
Bazel 서버는 지정된 명령어(
build,run,cquery등)에 대한 로드 및 분석 단계를 실행하여 메모리에서 빌드 그래프의 필요한 부분을 구성합니다. 결과 데이터 구조는 분석 캐시 의 일부로 Bazel 서버에 보관됩니다.Bazel 서버는 작업 실행을 실행할 수도 있고, 실행하도록 설정된 경우 원격 실행을 위해 작업을 전송할 수도 있습니다. 작업 실행 결과도 캐시됩니다. 즉, 작업 캐시 (또는 실행 캐시)에 캐시됩니다. 실행 캐시는 로컬 또는 원격일 수 있으며 Bazel 서버 간에 공유될 수 있습니다.
Bazel 호출 결과는 출력 트리에 제공됩니다.
Bazel 반복 실행
일반적인 개발자 워크플로에서는 코드를 반복적으로 빌드(또는 실행)하는 것이 일반적이며, 특히 컴파일 오류를 해결하거나 실패한 테스트를 조사하기 위해 매우 높은 빈도로 실행합니다. 이 경우 bazel의 반복 호출은 기본 반복 작업 (예: 컴파일러 호출 또는 테스트 실행)에 비해 오버헤드가 최대한 적어야 합니다.
이를 염두에 두고 Bazel의 런타임 상태를 다시 살펴보겠습니다.
분석 캐시는 중요한 데이터입니다. 콜드 실행 (즉, Bazel 서버가 시작된 직후 또는 분석 캐시가 삭제된 경우의 실행)의 로드 및 분석 단계에 상당한 시간이 소요될 수 있습니다. 단일의 성공적인 콜드 빌드 (예: 프로덕션 출시)의 경우 이 비용은 감당할 수 있지만 동일한 대상을 반복적으로 빌드하는 경우 이 비용은 상각되어야 하며 각 호출에서 반복되지 않아야 합니다.
분석 캐시는 다소 휘발성입니다. 우선 Bazel 서버의 인프로세스 상태의 일부이므로 서버가 손실되면 캐시가 손실됩니다. 하지만 캐시는 매우 쉽게 무효화 됩니다. 예를 들어 많은 bazel 명령줄 플래그로 인해 캐시가 삭제됩니다. 이는 많은 플래그가 구성 가능한 속성으로 인해 빌드
그래프에 영향을 미치기 때문입니다
. 일부 플래그
변경으로 인해 Bazel 서버가 다시 시작될 수도 있습니다 (예:
시작 옵션 변경).
실행 캐시가 양호하면 빌드 성능에도 유용합니다. 실행 캐시는 디스크에 로컬로 보관하거나 원격으로 보관할 수 있습니다. 캐시는 Bazel 서버 간에, 그리고 개발자 간에 공유될 수 있습니다.
분석 캐시 삭제 방지
분석 캐시가 삭제되었거나 서버가 다시 시작된 경우 Bazel에서 경고를 출력합니다. 반복 사용 중에 둘 다 피해야 합니다.
반복 워크플로 중간에
bazel플래그를 변경하지 않도록 주의하세요. 예를 들어bazel build -c opt와bazel cquery를 혼합하면 각 명령어가 다른 명령어의 분석 캐시를 삭제합니다. 일반적으로 특정 워크플로의 기간 동안 고정된 플래그 집합을 사용해 보세요.Bazel 서버가 손실되면 분석 캐시가 손실됩니다. Bazel 서버에는 구성 가능한 유휴 시간이 있으며, 이 시간이 지나면 종료됩니다. bazelrc 파일을 통해 필요에 맞게 이 시간을 구성할 수 있습니다. 시작 플래그가 변경되면 서버도 다시 시작되므로 가능하면 이러한 플래그를 변경하지 마세요.
주의: Bazel이 실행되는 동안 Ctrl-C를 반복적으로 누르면 Bazel 서버가 종료됩니다. 더 이상 필요하지 않은 실행 중인 빌드를 중단하여 시간을 절약하려고 할 수 있지만 Ctrl-C를 한 번만 눌러 현재 호출의 정상적인 종료를 요청하세요.
동일한 작업공간에서 여러 플래그 집합을 사용하려면
--output_base플래그로 전환되는 여러 개의 고유한 출력 기반을 사용할 수 있습니다. 각 출력 기반에는 자체 Bazel 서버가 있습니다.