我使用與aws lambda（java）集成的aws api網關，但是我在這種方法中看到了一些嚴重的問題。移除服務器並將您的應用程序擴展到盒子外的概念非常好，但這是我面臨的問題。我的lambda正在做2個簡單的事情 - 驗證從客戶端接收到的有效負載，然後將其發送到kinesis流，以便從另一個lambda進一步處理（您會問爲什麼我不直接發送到流並僅使用1 lambda我們只是說我想分離邏輯並有一層抽象，並且能夠告訴客戶他發送的是無效數據。）。AWS Lambda性能問題
在實施lambda I集成彈簧DI。到現在爲止還挺好。我開始進行性能測試。我模擬了50個併發用戶，每個請求之間有5秒請求發出4個請求。所以發生了什麼 - 在lambda的冷啓動中，我初始化了Spring的應用程序上下文，但似乎在lambda沒有啓動時有太多的同時請求正在做一些奇怪的事情。以下是上下文初始化時間的屏幕截圖。
我們從截圖中可以看到的是，用於初始化上下文的時間有很大的區別。我對發生的事情的假設是，當接收到如此多的請求並且沒有「活動的」lambda時，它會爲它們中的每一個初始化一個lambda容器，並同時「阻塞」它們中的一些（具有大時間18秒），直到其他人已經開始準備就緒。所以也許它可以在同一時間啓動容器的內部限制。問題是，如果你沒有平均分配的流量，這將不時發生，並且一些請求會超時。我們不希望發生這種情況。
所以接下來的事情就是做一些沒有彈簧容器的測試，因爲我的想法是「好的，初始化很重，讓我們只是簡單地將舊的Java對象初始化」。不幸的是，同樣的事情發生了（也許只是減少了一些請求的3s容器初始化）。下面是測試數據的更詳細的截圖：
所以我記錄了整個拉姆達執行時間（從施工到結束）時，室壁運動客戶端初始化和實際的發送數據到流因爲這些是lambda中最重的操作。我們仍然有18歲左右的大時代，但有趣的是時代在某種程度上是成比例的。因此，如果整個lambda需要18s，則大約7-8s是客戶端初始化，6-7用於將數據發送到流，還有4-5s用於lambda中的其他操作，目前只是驗證。另一方面，如果我們選擇其中一個小時間（這意味着它重新使用已經開始的lambda），也就是說， 820ms，kinesis客戶端初始化需要100ms，數據發送需要100ms，驗證需要400ms。所以這再一次推動了我內心的想法，因爲一些限制而使得一些睡眠。接下來的屏幕截圖展示什麼是下一輪的請求發生時，LAMDA已經啓動：
所以我們沒有這個大時代，是的，我們還是有一些一些比較大的三角形（這對我來說也很奇怪），但事情看起來好多了。
因此，我正在尋找來自實際知道引擎蓋下發生的事情的人的澄清，因爲這對於使用雲的嚴重應用程序來說並不是好行爲，因爲它是「無限」的可能性。
而另一個問題是在區域的帳戶中涉及到的所有lambda表達式的λ-200併發調用的其他限制。對我來說，這對於擁有大量流量的大型應用程序也是一個很大的限制。因此，我現在的商業案例（我不知道未來）或多或少會引發火災，並忘記了這一要求。我開始考慮以網關直接將數據發送到流的方式更改邏輯，另一個lambda正在考慮驗證和進一步處理。是的，我放棄了當前的抽象（我目前不需要），但是我多次提高應用程序可用性。你怎麼看？
好的，但時代在我的代碼計算（因爲你可以假設），那麼在最壞的情況下，這意味着（所提供的測試中，它是18歲），從處理對象初始化的時候用了18秒，分別整個代碼執行速度較慢 - 在某些調用中，與100-200ms相比，kinesis put操作時間爲6-7秒。所以代碼正在執行，但速度較慢。關於增加限制 - 很高興知道他們對這種查詢作出了快速反應。 –