Rumah  >  Artikel  >  Java  >  AWS SnapStart - Bahagian Mengukur sejuk dan hangat bermula dengan Java menggunakan algoritma pengumpulan sampah yang berbeza

AWS SnapStart - Bahagian Mengukur sejuk dan hangat bermula dengan Java menggunakan algoritma pengumpulan sampah yang berbeza

DDD
DDDasal
2024-09-24 06:16:44855semak imbas

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

pengenalan

Dalam bahagian sebelumnya dalam siri kami, kami mengukur permulaan sejuk fungsi Lambda dengan masa jalan Java 21 tanpa SnapStart didayakan, dengan SnapStart didayakan dan juga menggunakan pengoptimuman penyebuan invokasi DynamoDB dengan tetapan memori Lambda yang berbeza, saiz artifak penggunaan Lambda, Java pilihan kompilasi, (a) klien HTTP segerak dan penggunaan lapisan Lambda yang berbeza. Untuk semua ukuran ini kami menggunakan algoritma kutipan sampah lalai G1.

Dalam artikel ini kami ingin meneroka kesan algoritma pengumpulan sampah Java pada prestasi fungsi Lambda dengan masa jalan Java 21. Kami juga akan mengukur semula segala-galanya untuk G1 mempunyai hasil yang setanding dengan versi Java 21 kecil yang sama yang digunakan untuk semua algoritma pengumpulan sampah.

Algoritma pengumpulan Sampah Java

Untuk pengukuran kami, kami akan menggunakan algoritma pengumpulan Java berikut dengan tetapan lalainya (sila rujuk dokumentasi yang dipautkan untuk mendapatkan maklumat lebih terperinci tentang setiap algoritma):

  • Sampah-Didahulukan (G1) Pengumpul Sampah. Ini ialah algoritma kutipan sampah yang digunakan secara lalai. Anda boleh menetapkannya secara eksplisit dalam templat AWS SAM dengan menambahkan -XX:+UseG1GC pada pembolehubah persekitaran JAVA_TOOL_OPTIONS.
  • Pengumpul Selari. Anda boleh menetapkannya secara eksplisit dalam templat AWS SAM dengan menambahkan -XX:+UseParallelGC pada pembolehubah persekitaran JAVA_TOOL_OPTIONS.
  • Shenandoah GC. Oracle JDK tidak menyediakannya, tetapi Amazon Corretto 21 JDK menyediakannya. Anda boleh menetapkannya secara eksplisit dalam templat AWS SAM dengan menambahkan -XX:+UseShenandoahGC pada pembolehubah persekitaran JAVA_TOOL_OPTIONS.
  • Pengumpul Sampah Z. Terdapat 2 algoritma ZGC yang berbeza: lalai dan yang lebih baharu satu generasi. Anda boleh menetapkannya secara eksplisit dalam templat AWS SAM dengan menambahkan -XX:+UseZGC atau -XX:+UseZGC -XX:+ZGenerational pada pembolehubah persekitaran JAVA_TOOL_OPTIONS.

Mengukur sejuk dan hangat bermula dengan Java 21 menggunakan algoritma pengumpulan sampah yang berbeza

Dalam percubaan kami, kami akan menggunakan aplikasi yang diubah suai sedikit yang diperkenalkan pada bahagian 9. Anda boleh mencari kod aplikasi di sini. Pada asasnya terdapat 2 fungsi Lambda yang kedua-duanya bertindak balas kepada permintaan Gateway API dan mendapatkan semula produk mengikut id yang diterima daripada Gateway API daripada DynamoDB. Satu fungsi Lambda GetProductByIdWithPureJava21LambdaWithGCAlg boleh digunakan dengan dan tanpa SnapStart dan yang kedua GetProductByIdWithPureJava21LambdaAndPrimingWithGCAlg menggunakan penyebuan permintaan SnapStart dan DynamoDB.

Keputusan percubaan di bawah adalah berdasarkan pembiakan lebih daripada 100 sejuk dan kira-kira 100,000 panas bermula dengan eksperimen yang berlangsung selama kira-kira 1 jam. Untuk itu (dan percubaan dari artikel saya sebelum ini) saya menggunakan alat ujian beban hey, tetapi anda boleh menggunakan apa sahaja alat yang anda mahu, seperti Serverless-artillery atau Postman. Kami menjalankan percubaan dengan memberikan fungsi Lambda 1024 MB memori dan menggunakan JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" (Kompilasi klien Java tanpa pemprofilan) yang mempunyai pertukaran yang sangat baik antara masa mula sejuk dan hangat.

Malangnya saya tidak dapat membuat fungsi Lambda bermula dengan The Z Garbage Collector (dengan kedua-dua lalai dan generasi) mengalami ralat :

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.

Ia mencuba tetapan memori yang lebih besar sebagai 1024 seperti 2048 MB dan lebih banyak MB, tetapi ralat yang sama masih muncul.

Mari kita lihat hasil pengukuran kami dengan 3 algoritma kutipan sampah yang lain.

Singkatan c ialah untuk permulaan sejuk dan w adalah untuk permulaan hangat.

Masa mula sejuk (c) dan hangat (w) tanpa SnapStart didayakan dalam 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 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

Heure de démarrage à froid (c) et à chaud (w) avec SnapStart activé sans amorçage en 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

Heure de démarrage à froid (c) et à chaud (w) avec SnapStart activé et avec invocation DynamoDB Amorçage en 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 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

Conclusion

Dans cet article, nous avons exploré l'impact des algorithmes de garbage collection Java (G1, Parallel Collector et Shenandoah) sur les performances de la fonction Lambda avec le runtime Java 21. Nous avons constaté une grande différence entre les performances de ces algorithmes. En utilisant les paramètres par défaut avec G1 (celui par défaut), nous obtenons (parfois de loin) les temps de démarrage à froid et à chaud les plus bas. En utilisant SnapStart avec l'amorçage de la requête DynamoDB, les résultats de performances sont comme prévu beaucoup plus proches les uns des autres.

Veuillez vous référer à la documentation de chaque algorithme de récupération de place pour régler les paramètres tels que le mixage et la mémoire maximale, ce qui peut apporter une amélioration significative des performances et effectuer vos propres mesures.

Atas ialah kandungan terperinci AWS SnapStart - Bahagian Mengukur sejuk dan hangat bermula dengan Java menggunakan algoritma pengumpulan sampah yang berbeza. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn