소개

시리즈의 이전 부분에서는 SnapStart를 활성화하지 않고 SnapStart를 활성화한 상태에서 Java 21 런타임을 사용하여 Lambda 함수의 콜드 스타트를 측정했으며 다양한 Lambda 메모리 설정, Lambda 배포 아티팩트 크기, Java를 사용하여 DynamoDB 호출 프라이밍 최적화를 적용했습니다. 컴파일 옵션, (a) 동기식 HTTP 클라이언트 및 다양한 Lambda 레이어 사용. 이러한 모든 측정에는 기본 가비지 수집 알고리즘 G1을 사용했습니다.

이 기사에서는 Java 가비지 수집 알고리즘이 Java 21 런타임을 사용하는 Lambda 함수 성능에 미치는 영향을 살펴보고자 합니다. 또한 모든 가비지 수집 알고리즘에 사용되는 동일한 Java 21 마이너 버전과 비교 가능한 결과를 얻기 위해 G1에 대한 모든 것을 다시 측정할 것입니다.

Java 가비지 수집 알고리즘

측정을 위해 기본 설정으로 다음 Java 수집 알고리즘을 사용합니다(각 알고리즘에 대한 자세한 내용은 링크된 문서를 참조하십시오).

• G1(가비지 우선) 가비지 수집기. 이는 기본적으로 사용되는 가비지 수집 알고리즘입니다. JAVA_TOOL_OPTIONS 환경 변수에 -XX: UseG1GC를 추가하여 AWS SAM 템플릿에서 이를 명시적으로 설정할 수 있습니다.
• 병렬 수집기. JAVA_TOOL_OPTIONS 환경 변수에 -XX: UseParallelGC를 추가하여 AWS SAM 템플릿에서 이를 명시적으로 설정할 수 있습니다.
• 셰넌도어 GC. Oracle JDK는 이를 제공하지 않지만 Amazon Corretto 21 JDK는 제공합니다. JAVA_TOOL_OPTIONS 환경 변수에 -XX: UseShenandoahGC를 추가하여 AWS SAM 템플릿에서 명시적으로 설정할 수 있습니다.
• Z 가비지 컬렉터. ZGC 알고리즘에는 기본 알고리즘과 최신 1세대 알고리즘의 2가지가 있습니다. JAVA_TOOL_OPTIONS 환경 변수에 -XX: UseZGC 또는 -XX: UseZGC -XX: ZGenerational을 추가하여 AWS SAM 템플릿에서 이를 명시적으로 설정할 수 있습니다.

다양한 가비지 수집 알고리즘을 사용하여 Java 21로 콜드 및 웜 스타트 측정

우리 실험에서는 9부에서 소개한 약간 수정된 애플리케이션을 사용하겠습니다. 여기에서 애플리케이션 코드를 찾을 수 있습니다. 기본적으로 API 게이트웨이 요청에 응답하고 DynamoDB의 API 게이트웨이에서 받은 ID로 제품을 검색하는 2개의 Lambda 함수가 있습니다. 하나의 Lambda 함수 GetProductByIdWithPureJava21LambdaWithGCAlg는 SnapStart 유무에 관계없이 사용할 수 있으며 두 번째 GetProductByIdWithPureJava21LambdaAndPrimingWithGCAlg 함수는 SnapStart 및 DynamoDB 요청 호출 프라이밍을 사용합니다.

아래 실험 결과는 약 1시간 동안 진행된 실험으로 100회 이상의 콜드 스타트와 약 100,000회 이상의 웜 스타트를 재현한 결과입니다. 이를 위해(및 이전 기사의 실험) 부하 테스트 도구를 사용했지만 Serverless-artillery 또는 Postman과 같이 원하는 도구를 사용할 수 있습니다. 우리는 Lambda 함수에 1024MB 메모리를 제공하고 JAVA_TOOL_OPTIONS: "-XX: TieredCompilation -XX:TieredStopAtLevel=1"(프로파일링 없는 Java 클라이언트 컴파일)을 사용하여 콜드 시작과 웜 시작 시간 사이의 균형이 매우 잘 맞는 실험을 실행합니다.

안타깝게도 Z Garbage Collector(기본 및 세대 모두 포함)에서 오류가 발생하여 Lambda 함수를 시작할 수 없습니다.

Failed to commit memory (Operation not permitted)
[error][gc] Forced to lower max Java heap size from 872M(100%) to 0M(0%)
[error][gc] Failed to allocate initial Java heap (512M)
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

2048MB와 같은 1024로 더 큰 메모리 설정을 시도하고 더 많은 MB를 시도했지만 여전히 동일한 오류가 나타납니다.

다른 3가지 가비지 수집 알고리즘을 이용한 측정 결과를 살펴보겠습니다.

약어 c는 콜드 스타트를 나타내고 w는 웜 스타트를 나타냅니다.

ms 단위로 SnapStart를 활성화하지 않은 콜드(c) 및 웜(w) 시작 시간:

초기화 없이 SnapStart를 활성화한 콜드(c) 및 웜(w) 시작 시간(밀리초):

SnapStart가 활성화되고 DynamoDB 호출이 활성화된 콜드(c) 및 웜(w) 시작 시간(ms 단위):

결론

이 기사에서는 Java 가비지 수집 알고리즘(G1, Parallel Collector 및 Shenandoah)이 Java 21 런타임을 사용하는 Lambda 함수의 성능에 미치는 영향을 살펴보았습니다. 우리는 해당 알고리즘의 성능에 상당한 차이가 있음을 확인했습니다. G1(기본 설정)과 함께 기본 설정을 사용하면 (때때로 훨씬) 가장 낮은 콜드 및 웜 시작 시간이 발생합니다. DynamoDB 요청 프라이밍과 함께 SnapStart를 사용하면 예상대로 성능 결과가 서로 훨씬 더 가까워집니다.

각 가비지 수집 알고리즘의 문서를 참조하여 성능을 크게 향상시키고 자체 측정을 ​​수행할 수 있는 혼합 및 최대 메모리와 같은 설정을 조정하세요.