시리즈의 이전 부분에서는 SnapStart를 활성화하지 않고 SnapStart를 활성화한 상태에서 Java 21 런타임을 사용하여 Lambda 함수의 콜드 스타트를 측정했으며 다양한 Lambda 메모리 설정, Lambda 배포 아티팩트 크기, Java를 사용하여 DynamoDB 호출 프라이밍 최적화를 적용했습니다. 컴파일 옵션, (a) 동기식 HTTP 클라이언트 및 다양한 Lambda 레이어 사용. 이러한 모든 측정에는 기본 가비지 수집 알고리즘 G1을 사용했습니다.
이 기사에서는 Java 가비지 수집 알고리즘이 Java 21 런타임을 사용하는 Lambda 함수의 성능에 미치는 영향을 살펴보고자 합니다. 또한 모든 가비지 수집 알고리즘에 사용되는 동일한 Java 21 마이너 버전과 비교 가능한 결과를 얻기 위해 G1에 대한 모든 것을 다시 측정할 것입니다.
측정을 위해 기본 설정으로 다음 Java 수집 알고리즘을 사용합니다(각 알고리즘에 대한 자세한 내용은 링크된 문서를 참조하세요).
우리 실험에서는 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는 Cold Start, w는 Warm Start를 의미합니다.
ms 단위로 SnapStart를 활성화하지 않은 콜드(c) 및 웜(w) 시작 시간:
| GC Algorithm | c p50 | c p75 | c p90 | c p99 | c p99.9 | c max | w p50 | w p75 | w p90 | w p99 | w p99.9 | w max |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| G1 | 3655.17 | 3725.25 | 3811.88 | 4019.25 | 4027.30 | 4027.83 | 5.46 | 6.10 | 7.10 | 16.79 | 48.06 | 1929.79 |
| Parallel Collector | 3714.10 | 3789.09 | 3857.87 | 3959.44 | 4075.89 | 4078.25 | 5.55 | 6.20 | 7.10 | 15.38 | 130.13 | 2017.92 |
| Shenandoah | 3963.40 | 4019.25 | 4096.30 | 4221.00 | 4388.78 | 4390.76 | 5.82 | 6.45 | 7.39 | 17.06 | 71.02 | 2159.21 |
프라이밍 없이 SnapStart를 활성화한 콜드(c) 및 웜(w) 시작 시간(ms):
| GC Algorithm | c p50 | c p75 | c p90 | c p99 | c p99.9 | c max | w p50 | w p75 | w p90 | w p99 | w p99.9 | w max |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| G1 | 1867.27 | 1935.68 | 2152.02 | 2416.57 | 2426.25 | 2427.35 | 5.47 | 6.11 | 7.05 | 17.41 | 51.24 | 1522.04 |
| Parallel Collector | 1990.62 | 2047.12 | 2202.07 | 2402.12 | 2418.99 | 2419.32 | 5.68 | 6.35 | 7.45 | 18.04 | 147.83 | 1577.21 |
| Shenandoah | 2195.47 | 2301.07 | 2563.37 | 3004.89 | 3029.01 | 3030.36 | 5.73 | 6.41 | 7.51 | 17.97 | 75.00 | 1843.34 |
SnapStart가 활성화되고 DynamoDB 호출 프라이밍(ms)을 사용한 콜드(c) 및 웜(w) 시작 시간:
| GC Algorithm | c p50 | c p75 | c p90 | c p99 | c p99.9 | c max | w p50 | w p75 | w p90 | w p99 | w p99.9 | w max |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| G1 | 833.50 | 875.34 | 1089.53 | 1205.26 | 1269.56 | 1269.8 | 5.46 | 6.10 | 7.16 | 16.39 | 46.19 | 499.13 |
| Parallel Collector | 900.18 | 975.12 | 1058.41 | 1141.94 | 1253.17 | 1253.99 | 5.82 | 6.61 | 7.75 | 16.87 | 49.64 | 487.73 |
| Shenandoah | 1065.84 | 1131.71 | 1331.96 | 1473.44 | 1553.59 | 1554.95 | 5.77 | 6.40 | 7.39 | 17.20 | 65.06 | 500.48 |
이 기사에서는 Java 가비지 수집 알고리즘(G1, Parallel Collector 및 Shenandoah)이 Java 21 런타임을 사용하는 Lambda 함수 성능에 미치는 영향을 살펴보았습니다. 우리는 해당 알고리즘의 성능에 상당한 차이가 있음을 확인했습니다. G1(기본 설정)과 함께 기본 설정을 사용하면 (때때로 훨씬) 가장 낮은 콜드 및 웜 시작 시간이 발생합니다. DynamoDB 요청 프라이밍과 함께 SnapStart를 사용하면 예상대로 성능 결과가 서로 훨씬 더 가까워집니다.
각 가비지 수집 알고리즘의 문서를 참조하여 성능을 크게 향상시킬 수 있는 혼합 및 최대 메모리와 같은 설정을 조정하고 직접 측정해 보세요.
위 내용은 AWS SnapStart - 다양한 가비지 수집 알고리즘을 사용하여 Java로 콜드 및 웜 스타트 측정하는 부분의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
