이 페이지에서는 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 서버가 있습니다.