無服務平臺效能比較
大多數主要的雲服務供應商都有可以提供功能即服務（FaaS）的無服務平臺。最近一些基準測評研究了它們之間在執行時間、冷啟動時間、依賴性和資源分配方面的效能區別。
ofollow,noindex" target="_blank">Bernd Strehl 測評 了無服務供應商AWS Lambda、Google Cloud Functions、Azure Functions 和IBM Cloud Functions之間的效能區別。這些測評使用了Node.js功能，儘管展示了不同供應商對請求負載響應的差異，但是這種測試方法所使用的樣本太少，而卻沒有考慮到其他的一些因素，比如底層例項型別，因此受到了質疑 。其他團隊的測評 用了不同的InformalProceedings.pdf" rel="nofollow,noindex" target="_blank">方法 。
無服務供應商不僅要考慮CPU、記憶體和請求數量，還要考慮網路和儲存。不同供應商對於如何根據特定的CPU需求來調整記憶體都存在差異，例如，AWS給配備較高記憶體的例項提供更多的CPU週期 。Google也採用了類似的策略，而Azure對於CPU分配的策略則不同，“4-vCPU的虛擬機器將分配更多CPU”。
併發請求改變了功能的平均響應時間。對於非併發請求，幾乎所有的供應商資源分配都相同，除了Google大約有30%左右的偏差。對於併發請求，當同時執行50個相同的呼叫，AWS的計算時間增加了46%，Google和Azure分別為7%和3%，IBM為154%。其他的測評表 明 ，AWS在併發處理方面有最好的效能表現。
冷啟動時間是無服務功能在一段時間沒有使用後響應第一個請求所需要的時間。研究結果表明，要維持效能不變對所有的供應商來說都是一個挑戰。雲供應商一般會不間斷地執行一組一般性的worker（即worker pool）。第一個進站的請求獲得其中一個例項，該例項負責處理這個請求。例項在處理完第一個請求後保持執行狀態。不過，保持執行的時間長短因供應商不同而不同。M ikhail Shilkov 在他的一篇文章 中說明了Azure的冷啟動時間是20分鐘，而Google Cloud Functions時間則不定。AWS官方宣佈的時間是5分鐘，但實際時間更長，因為他們的工程團隊進行了調整。當服務需要橫向擴充套件，需要加入新的服務例項時也會發生冷啟動。
執行時的選擇也會影響效能。Node.js應用程式不需要啟動很多CPU，而.NET Core執行時需要更多記憶體（在AWS Lambda中）。冷啟動時間隨著分配的記憶體的增加而減少。測評表明，對於Javascript而言，AWS的冷啟動時間最快，之後是GCP和Azure。
檢視英文原文：Serverless Platforms Compared for Performance
感謝無明對本文的審校。