AWS SnapStart - 다양한 가비지 수집 알고리즘을 사용하여 Java로 콜드 및 웜 스타트 측정하는 부분-java지도 시간-php.cn

집

Java

java지도 시간

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

DDD

Sep 24, 2024 am 06:16 AM

AWS SnapStart - Part Measuring cold and warm starts with Java using different garbage collection algorithms

소개

시리즈의 이전 부분에서는 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는 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 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명

본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

관련 기사

Java 응용 프로그램에서 플랫폼 별 문제를 완화하기위한 몇 가지 전략은 무엇입니까?May 01, 2025 am 12:20 AM

Java는 플랫폼 별 문제를 어떻게 완화합니까? Java는 JVM 및 표준 라이브러리를 통해 플랫폼 독립성을 구현합니다. 1) Bytecode 및 JVM을 사용하여 운영 체제 차이를 추상화합니다. 2) 표준 라이브러리는 Paths 클래스 처리 파일 경로 및 Charset 클래스 처리 문자 인코딩과 같은 크로스 플랫폼 API를 제공합니다. 3) 최적화 및 디버깅을 위해 실제 프로젝트에서 구성 파일 및 다중 플랫폼 테스트를 사용하십시오.

Java의 플랫폼 독립성과 마이크로 서비스 아키텍처의 관계는 무엇입니까?May 01, 2025 am 12:16 AM

java'splatformincendenceenhancesmicroservicesarchitectureDeploymentFlexibility, 일관성, 확장 성 및 포트 가능성

Graalvm은 Java의 플랫폼 독립 목표와 어떤 관련이 있습니까?May 01, 2025 am 12:14 AM

Graalvm은 Java의 플랫폼 독립성을 세 가지 방식으로 향상시킵니다. 1. 교차 언어 상호 운용성, Java는 다른 언어와 원활하게 상호 작용할 수 있습니다. 2. 독립적 인 런타임 환경, Java 프로그램을 GraalvMnativeImage를 통해 로컬 실행 파일로 컴파일합니다. 3. 성능 최적화, Graal Compiler는 Java 프로그램의 성능과 일관성을 향상시키기 위해 효율적인 기계 코드를 생성합니다.

플랫폼 호환성을 위해 Java 응용 프로그램을 어떻게 테스트합니까?May 01, 2025 am 12:09 AM

ToEffectIallyTestJavaApplicationSforplatformcompatibility, followthesesteps : 1) setupAutomatedTestingAcrossMultiplePlatflatformsUsingCitools likeJenkinsorgitHubactions.2) 행동 관리자는 realHardwaretoCathissesnotfoundInvironmentments.3) Checkcross-Pla

플랫폼 독립성을 달성하는 데있어 Java Compiler (Javac)의 역할은 무엇입니까?May 01, 2025 am 12:06 AM

Java Compiler는 소스 코드를 플랫폼 독립적 인 바이트 코드로 변환하여 Java의 플랫폼 독립성을 실현하여 JVM이 설치된 JVM 프로그램에서 모든 운영 체제에서 실행할 수 있습니다.

플랫폼 독립성을 위해 기본 코드를 통해 바이트 코드를 사용하는 장점은 무엇입니까?Apr 30, 2025 am 12:24 AM

Bytecodeachievesplatformincendence는 executedbirtualmachine (vm)을 beenecutedbyavirtmachine (vm)을 허용합니다

Java는 진정으로 100% 플랫폼 독립적입니까? 왜 또는 왜 그렇지 않습니까?Apr 30, 2025 am 12:18 AM

Java는 100% 플랫폼 독립성을 달성 할 수 없지만 플랫폼 독립성은 JVM 및 바이트 코드를 통해 구현되어 코드가 다른 플랫폼에서 실행되도록합니다. 특정 구현에는 다음이 포함됩니다. 1. 바이트 코드로의 컴파일; 2. JVM의 해석 및 실행; 3. 표준 라이브러리의 일관성. 그러나 JVM 구현 차이, 운영 체제 및 하드웨어 차이, 타사 라이브러리의 호환성은 플랫폼 독립성에 영향을 줄 수 있습니다.