


Aplikasi Spring Boot pada AWS Lambda - Bahagian Mengukur sejuk dan hangat bermula dengan tetapan Imej Asli dan memori GraalVM
Jan 07, 2025 am 07:17 AMpengenalan
Dalam artikel bahagian 12 siri kami, kami meneroka cara membangunkan dan menggunakan fungsi Lambda dengan Masa Jalan Tersuai yang mengandungi Imej Asli GraalVM dengan masa jalan GraalVM 22 yang dicipta daripada aplikasi Spring Cloud Function AWS. Dalam bahagian 13 kami mengukur prestasi (permulaan sejuk dan hangat) fungsi Lambda sedemikian dengan memori 1024 MB.
Dalam artikel ini, kami akan mengukur prestasi (permulaan sejuk dan hangat) fungsi Lambda menggunakan pendekatan ini dengan tetapan memori berbeza antara 256 dan 1536 MB untuk meneroka pertukaran antara kos dan prestasi.
Mengukur permulaan sejuk dan hangat fungsi Lambda dengan Masa Jalan Tersuai yang mengandungi Imej Asli GraalVM dengan tetapan memori yang berbeza
Kami akan menggunakan semula percubaan sama yang diterangkan dalam bahagian 13 siri artikel ini tetapi dengan tetapan memori yang berbeza antara 256 dan 1536 MB.
Berikut ialah hasil percubaan:
Masa mula sejuk (c) dan hangat (m) dalam ms:
Memory setting | 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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
256 MB | 1634.84 | 1659.54 | 1691.35 | 1778.03 | 1785.15 | 1785.7 | 6.56 | 6.99 | 7.63 | 18.33 | 372.54 | 857.7 |
512 MB | 1244.44 | 1278.48 | 1313.45 | 1414.28 | 1421.36 | 1421.94 | 6.66 | 7.10 | 7.94 | 25.41 | 181.86 | 414.99 |
768 MB | 1111.53 | 1126.07 | 1139.66 | 1192.08 | 1202.86 | 1203.07 | 6.58 | 6.93 | 7.48 | 12.46 | 115.18 | 278.91 |
1024 MB | 1051.03 | 1061.58 | 1080.86 | 1119.34 | 1149.45 | 1230.28 | 6.45 | 6.77 | 7.33 | 12.50 | 90.92 | 218.17 |
1280 MB | 1022.02 | 1035.39 | 1058.41 | 1065.76 | 1104.64 | 1174.79 | 6.58 | 6.96 | 7.54 | 12.37 | 70.77 | 271.13 |
1536 MB | 1009.83 | 1029.20 | 1048.41 | 1161.32 | 1116.24 | 1148.24 | 6.66 | 7.04 | 7.75 | 12.08 | 63.03 | 215.62 |
Kesimpulan
Dalam artikel ini, suhu dan sejuk yang diukur bermula bagi fungsi Lambda menggunakan Masa Jalan Tersuai yang mengandungi Imej Asli GraalVM dengan masa jalan GraalVM 21 yang dicipta daripada aplikasi Spring Cloud Function AWS yang diperkenalkan dalam bahagian 12 yang mempunyai tetapan memori berbeza antara 256 dan 1536 MB.
Kami melihat perkara yang serupa seperti yang diterangkan dalam artikel Fungsi Lambda Tulen dengan Imej Asli GraalVM - Mengukur permulaan sejuk dan hangat menggunakan tetapan memori Lambda yang berbeza. Masa mula panas adalah sangat hampir antara satu sama lain juga dengan tetapan memori fungsi Lambda yang lebih rendah seperti 256 atau 512 MB di mana perbezaannya kelihatan terutamanya untuk persentil tinggi (>= p90). Masa mula sejuk agak tinggi untuk 256 dan 512 MB dan bermula dari 768 MB memori ia berkurangan sedikit sahaja dengan memberikan Lambda lebih banyak memori, tetapi tanpa sebarang perbezaan ketara untuk memori yang lebih besar daripada 1024 MB. Bergantung pada keperluan prestasi anda, anda boleh memberikan Lambda kurang memori daripada 1024 MB seperti yang kami berikan pada mulanya dalam aplikasi sampel dan mempunyai pertukaran prestasi harga yang sangat baik dengan 768 MB atau lebih kurang memori.
Kami juga berkongsi pemerhatian yang sama seperti yang diterangkan dalam kesimpulan bahagian 13. Apabila kami membandingkan masa mula sejuk dengan yang diukur dalam artikel Fungsi Lambda Tulen dengan Imej Asli GraalVM - Mengukur permulaan sejuk dan hangat menggunakan tetapan memori Lambda yang berbeza ( di mana fungsi Lambda tidak menggunakan sebarang rangka kerja seperti Spring Boot), kami melihat nilai kira-kira 0.5-0.6 saat lebih rendah untuk setiap persentil apabila menggunakan fungsi Lambda tulen. Saya secara peribadi berpendapat bahawa sampel aplikasi Spring Boot 3 saya mempunyai beberapa potensi pengoptimuman kerana saya tidak dapat menjelaskan perbezaan yang begitu besar dalam masa mula sejuk antara mereka. Jangkaan saya (mungkin naif) ialah penggunaan rangka kerja Spring Boot 3 dengan imej AWS Lambda dan GraalVM Native hanya boleh membawa kepada 0.2-0.3 masa mula sejuk yang lebih tinggi berbanding dengan penggunaan fungsi Lambda tulen.
Pada masa penerbitan artikel ini, versi rangka kerja dan alatan yang lebih baharu telah tersedia (masa jalan GraalVM 23, Spring Boot 3.4 dan kemas kini versi pustaka Spring Cloud Function) supaya anda membuat perubahan versi dan menyusun semula GraalVM Native imej mengikut arahan dari bahagian 2 siri dan ukur semula prestasi. Saya juga tidak lama lagi akan menerbitkan ukuran baharu dengan versi ini dan menaik taraf aplikasi contoh.
Atas ialah kandungan terperinci Aplikasi Spring Boot pada AWS Lambda - Bahagian Mengukur sejuk dan hangat bermula dengan tetapan Imej Asli dan memori GraalVM. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Alat AI Hot

Undress AI Tool
Gambar buka pakaian secara percuma

Undresser.AI Undress
Apl berkuasa AI untuk mencipta foto bogel yang realistik

AI Clothes Remover
Alat AI dalam talian untuk mengeluarkan pakaian daripada foto.

Clothoff.io
Penyingkiran pakaian AI

Video Face Swap
Tukar muka dalam mana-mana video dengan mudah menggunakan alat tukar muka AI percuma kami!

Artikel Panas

Alat panas

Notepad++7.3.1
Editor kod yang mudah digunakan dan percuma

SublimeText3 versi Cina
Versi Cina, sangat mudah digunakan

Hantar Studio 13.0.1
Persekitaran pembangunan bersepadu PHP yang berkuasa

Dreamweaver CS6
Alat pembangunan web visual

SublimeText3 versi Mac
Perisian penyuntingan kod peringkat Tuhan (SublimeText3)

Topik panas

Perbezaan antara hashmap dan hashtable terutamanya dicerminkan dalam keselamatan benang, sokongan nilai null dan prestasi. 1. Dari segi keselamatan benang, hashtable adalah benang selamat, dan kaedahnya kebanyakannya kaedah segerak, sementara hashmap tidak melakukan pemprosesan penyegerakan, yang bukan benang-selamat; 2. Dari segi sokongan nilai null, hashmap membolehkan satu kunci null dan nilai null berbilang, manakala hashtable tidak membenarkan kekunci atau nilai null, jika tidak, nullPointerException akan dibuang; 3. Dari segi prestasi, hashmap lebih cekap kerana tidak ada mekanisme penyegerakan, dan Hashtable mempunyai prestasi penguncian yang rendah untuk setiap operasi. Adalah disyorkan untuk menggunakan ConcurrentHashMap sebaliknya.

Java menggunakan kelas pembalut kerana jenis data asas tidak dapat mengambil bahagian secara langsung dalam operasi berorientasikan objek, dan bentuk objek sering diperlukan dalam keperluan sebenar; 1. Kelas koleksi hanya boleh menyimpan objek, seperti senarai menggunakan tinju automatik untuk menyimpan nilai berangka; 2. Generik tidak menyokong jenis asas, dan kelas pembungkusan mesti digunakan sebagai parameter jenis; 3. Kelas pembungkusan boleh mewakili nilai null untuk membezakan data yang tidak tersendiri atau hilang; 4. Kelas pembungkusan menyediakan kaedah praktikal seperti penukaran rentetan untuk memudahkan parsing dan pemprosesan data, jadi dalam senario di mana ciri -ciri ini diperlukan, kelas pembungkusan sangat diperlukan.

Staticmethodsininterfaceswereintroducedinjava8toallowutilityfunctionswithintheintheinterfaceitself.beforjava8, SuchfunctionsRequiredseparateHelpereHelperes, LeadingTodisorgaganizedCode.Now, staticmethodethreeKeybeeMeKeBeReSes, staticmethodeDethreeKeybeeMeKeBeReSes, staticmethodethreeKeybeeMeKeKeBeReSes, staticmethodeDethreeKeybeeMeKeKeBeReKeNey

Penyusun JIT mengoptimumkan kod melalui empat kaedah: kaedah dalam talian, pengesanan tempat panas dan penyusunan, spekulasi jenis dan devirtualisasi, dan penghapusan operasi yang berlebihan. 1. Kaedah sebaris mengurangkan panggilan overhead dan memasukkan kaedah kecil yang sering dipanggil terus ke dalam panggilan; 2. Pengesanan tempat panas dan pelaksanaan kod frekuensi tinggi dan mengoptimumkannya untuk menjimatkan sumber; 3. Jenis spekulasi mengumpul maklumat jenis runtime untuk mencapai panggilan devirtualisasi, meningkatkan kecekapan; 4. Operasi berlebihan menghapuskan pengiraan dan pemeriksaan yang tidak berguna berdasarkan penghapusan data operasi, meningkatkan prestasi.

Blok permulaan contoh digunakan dalam Java untuk menjalankan logik inisialisasi apabila membuat objek, yang dilaksanakan sebelum pembina. Ia sesuai untuk senario di mana beberapa pembina berkongsi kod inisialisasi, permulaan medan kompleks, atau senario permulaan kelas tanpa nama. Tidak seperti blok inisialisasi statik, ia dilaksanakan setiap kali ia ditegaskan, manakala blok permulaan statik hanya dijalankan sekali apabila kelas dimuatkan.

Injava, thefinalkeywordpreventsavariable'svaluefrombeingchangedafterassignment, butitsbehaviordiffersforprimitivesandobjectreferences.forprimitiveVariables, finalmakesthevalueconstant, asinfinalintmax_speed = 100;

Mod kilang digunakan untuk merangkum logik penciptaan objek, menjadikan kod lebih fleksibel, mudah dikekalkan, dan ditambah longgar. Jawapan teras adalah: dengan mengurus logik penciptaan objek secara berpusat, menyembunyikan butiran pelaksanaan, dan menyokong penciptaan pelbagai objek yang berkaitan. Keterangan khusus adalah seperti berikut: Mod Kilang menyerahkan penciptaan objek ke kelas kilang khas atau kaedah untuk diproses, mengelakkan penggunaan Newclass () secara langsung; Ia sesuai untuk senario di mana pelbagai jenis objek yang berkaitan dicipta, logik penciptaan boleh berubah, dan butiran pelaksanaan perlu disembunyikan; Sebagai contoh, dalam pemproses pembayaran, jalur, paypal dan contoh lain dicipta melalui kilang -kilang; Pelaksanaannya termasuk objek yang dikembalikan oleh kelas kilang berdasarkan parameter input, dan semua objek menyedari antara muka yang sama; Varian biasa termasuk kilang -kilang mudah, kaedah kilang dan kilang abstrak, yang sesuai untuk kerumitan yang berbeza.

Terdapat dua jenis penukaran: tersirat dan eksplisit. 1. Penukaran tersirat berlaku secara automatik, seperti menukar int untuk berganda; 2. Penukaran eksplisit memerlukan operasi manual, seperti menggunakan (int) mydouble. Kes di mana penukaran jenis diperlukan termasuk memproses input pengguna, operasi matematik, atau lulus pelbagai jenis nilai antara fungsi. Isu-isu yang perlu diperhatikan adalah: Mengubah nombor terapung ke dalam bilangan bulat akan memotong bahagian pecahan, mengubah jenis besar menjadi jenis kecil boleh menyebabkan kehilangan data, dan beberapa bahasa tidak membenarkan penukaran langsung jenis tertentu. Pemahaman yang betul tentang peraturan penukaran bahasa membantu mengelakkan kesilapan.
