Aleksandr Filichkin-5分鐘閱讀

讓我們比較一下所有支持的運(yùn)行時(shí)+2個(gè)自定義運(yùn)行時(shí)（Rust和GraalVM）的性能。

將比較冷啟動(dòng)和熱啟動(dòng)。

源代碼在這里：https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-performance。它需要最小的本地設(shè)置（幾乎所有的都是Docker化的）。

• NodeJs (14.x)

• Python (3.9)

• Go(1.x)

• Ruby(2.7)

• .Net(3.1)

• Java (11)

• Rust(1.54.0)

• GraalVM(21.2)

免責(zé)聲明。

所有的基準(zhǔn)都是在2021年9月進(jìn)行的

我不是所有這些語(yǔ)言的專家，我很高興看到GitHub repo中的MR有性能改進(jìn)。我將支持這些 repo，并每三個(gè)月進(jìn)行一次性能測(cè)試。我相信開(kāi)放源碼的合作 :)

測(cè)試場(chǎng)景

我們將測(cè)試API-Gateway->AWS Lambda->DynamoDb流程。

我們將只測(cè)試POST端點(diǎn)，它將把數(shù)據(jù)保存到已知的AWS區(qū)域（us-east-2）的DynamoDb表中。

主要流程

冷啟動(dòng)測(cè)試

我盡了一切努力來(lái)減少冷啟動(dòng)。

• 刪除了無(wú)用的依賴性。

• 盡可能多地移到初始化階段（例如，在Java中把所有東西移到靜態(tài)），以便在啟動(dòng)時(shí)使用CPU的爆發(fā)。

• 指定了區(qū)域。

• 擺脫了任何DI框架

結(jié)果。

冷啟動(dòng)結(jié)果

冷啟動(dòng)結(jié)果

• 所有語(yǔ)言（除了Java和.Net）都有一個(gè)相當(dāng)小的冷啟動(dòng)。

• Java甚至不能用128Mb啟動(dòng)。它需要更多的內(nèi)存。但GraalVM在這種情況下可以提供幫助。請(qǐng)隨意閱讀關(guān)于GraalVM和AWS Lambda的詳細(xì)頁(yè)面

• 在所有的設(shè)置中，Rust擊敗了所有的其它語(yǔ)言，唯一的例外是128MB的Python是最好的。

• 龐大的設(shè)置只對(duì)Java和.Net有幫助。

熱啟動(dòng)測(cè)試

測(cè)試是向每個(gè)lambda逐一發(fā)送15，000個(gè)請(qǐng)求。

對(duì)于負(fù)載測(cè)試，我使用JMeter。它看起來(lái)像。

我們將檢查哪些指標(biāo)？

• 每種語(yǔ)言的平均（每分鐘）持續(xù)時(shí)間（256MB設(shè)置，（128MB的簡(jiǎn)短結(jié)果你可以在最后找到）。

• 每種語(yǔ)言的最長(zhǎng)（每分鐘）時(shí)間（256MB設(shè)置）。

NodeJS

NodeJS有一個(gè)預(yù)期的行為。

開(kāi)始的時(shí)候很慢，但經(jīng)過(guò)JIT優(yōu)化后會(huì)變得更好。

NodeJS 256MB的平均持續(xù)時(shí)間

NodeJS 256MB的最大持續(xù)時(shí)間

Python

具有穩(wěn)定的性能：第100次和第15000次調(diào)用是一樣的。

Python 256MB的平均持續(xù)時(shí)間

Python 最大持續(xù)時(shí)間為256MB

Ruby

我觀察到Ruby非常奇怪的行為：平均持續(xù)時(shí)間在增長(zhǎng)（看起來(lái)像是內(nèi)存泄漏或代碼中的錯(cuò)誤）。

紅寶石256MB的平均時(shí)間

紅寶石 256MB 最大持續(xù)時(shí)間

.NET

最初的~1千次調(diào)用很慢，但隨后它的性能非常好。

.Net 256MB的平均持續(xù)時(shí)間

.Net的最大持續(xù)時(shí)間為256MB

Golang

穩(wěn)定的彈性性能。

Golang 256MB的平均持續(xù)時(shí)間

Golang 256MB的最大持續(xù)時(shí)間

Java

最初的~1千次迭代很慢，然后變得更快（JIT C1有幫助）。

Java 256MB的平均時(shí)間

Java最大持續(xù)時(shí)間為256MB

對(duì)于Java，我期望C2 JIT優(yōu)化在1萬(wàn)次迭代后進(jìn)行，但即使在2萬(wàn)次調(diào)用后也沒(méi)有優(yōu)化，而且持續(xù)時(shí)間是一樣的。請(qǐng)看下面的屏幕。

Java 256 MB，沒(méi)有C2優(yōu)化。

GraalVM

正如預(yù)期的那樣，GraalVM從一開(kāi)始就具有穩(wěn)定的良好性能。

GraalVM 256MB的平均時(shí)間

GraalVM 256MB的最大持續(xù)時(shí)間

Rust

Rust有一個(gè)持續(xù)的令人敬畏的表現(xiàn)。

Rust 256MB的平均持續(xù)時(shí)間

Rust 256MB的最大持續(xù)時(shí)間

全部在一起

衡量平均性能是非常棘手的，因?yàn)槊恳粋€(gè)新的lambda都有一些不同的結(jié)果（我相信這是因?yàn)閘ambdas在不同的硬件上分配）。我運(yùn)行了3次測(cè)試，兩次測(cè)試之間有30分鐘的延遲，以便有3個(gè)不同的lambdas分配。

3個(gè)時(shí)間段的5K迭代（256MB Lambda）。

256 MB Lambda

此外，我還測(cè)試了128MB lambda的相同流量。在這里我們可以看到一個(gè)很大的區(qū)別。

128MB的平均溫度狀態(tài)

128MB的平均溫度狀態(tài)

最大128MB（每分鐘）溫?zé)釥顟B(tài)

我想對(duì)于CPU密集型的流程來(lái)說(shuō)，編譯語(yǔ)言和解釋語(yǔ)言之間的差異會(huì)更大。我想，GraalVM在128MB的情況下表現(xiàn)不佳，因?yàn)樗锩孢€有JVM，它需要太多的內(nèi)存，而且Lambda經(jīng)常執(zhí)行GC。

結(jié)論

冷啟動(dòng)

• 所有語(yǔ)言（除了Java和.Net）都有一個(gè)相當(dāng)小的冷啟動(dòng)。

• Java甚至不能用128Mb啟動(dòng)。它需要更多的內(nèi)存。但GraalVM在這種情況下可以提供幫助。

• 在所有的設(shè)置中，Rust在冷啟動(dòng)時(shí)都勝過(guò)所有的運(yùn)行時(shí)間，唯一的例外是128MB，Python是最好的。

熱啟動(dòng)

• Golang和Rust是贏家。他們有同樣出色的表現(xiàn)。

• .Net的性能幾乎與Golang和Rust相同，但只是在1千次迭代后（JIT后）。

• GraalVM有一個(gè)穩(wěn)定的偉大的性能，幾乎與.Net相同，比Rust和Golang差一點(diǎn)。但對(duì)于最小的設(shè)置來(lái)說(shuō)， 它的性能并不理想。

• 與.Net一樣，Java也需要一些時(shí)間（1-3千次迭代）進(jìn)行JIT（C1）。不幸的是，在這個(gè)特定的用例中，我無(wú)法在JIT C2編譯后達(dá)到預(yù)期的良好性能。也許AWS只是禁用了它。

• Python具有穩(wěn)定的良好性能，但對(duì)于128MB的計(jì)算機(jī)來(lái)說(shuō)工作速度太慢。

• Ruby的性能幾乎與Python相同，但我們看到在20分鐘的調(diào)用后（15000次迭代后），一些持續(xù)時(shí)間在增長(zhǎng)。

• NodeJs是最慢的運(yùn)行時(shí)間，經(jīng)過(guò)一段時(shí)間后，它變得更好了（JIT），但仍然不夠好。此外，我們看到NodeJS的最大持續(xù)時(shí)間最差。

冷+暖啟動(dòng)的贏家是Golang和Rust。它們總是比其他運(yùn)行時(shí)更快，并表現(xiàn)出非常穩(wěn)定的結(jié)果。