負載測試下節點Js響應時間減少

我正在爲我們現有的應用程序寫一個概念驗證。負載測試下節點Js響應時間減少

現有應用程序的體系結構： Soap Web服務暴露給其他系統。我們現有系統的技術堆棧： - Java - > C++ - >存儲過程（Oracle Database）。大部分業務邏輯都是用存儲過程編寫的。

問題是在節點js中做一個概念驗證，它將取代現有的Java和C++層。建議的架構是Node Js - > Stored procedures（Oracle數據庫）。

我有幾個問題：

在節點JS概念（與快遞）的證明工作正常，直到100個併發用戶/秒，其中響應時間是下了1秒。隨着併發用戶數量的增加，響應時間也增加並超過1秒（現有應用程序的SLA小於1秒）。應用程序部署在EC2實例上（與t2.micro和m4.large結果相同，數據庫也是RDS實例）。我也嘗試過使用集羣，但沒有顯着的增益表現。

我該如何改進，直到1000用戶/秒，響應時間保持在1秒以下。
是否有任何其他適合此場景的語言/框架？

來源

2017-08-17 Rahul Jha

問題是：什麼是需要時間？找出並調整它。也許遵循標準的「調整應用程序，然後調整SQL，然後調整數據庫」的方法。並調整網絡和操作系統，並... –

謝謝克里斯託弗。由於目前的架構已經能夠達到預期的響應時間，數據庫方面似乎沒有問題。 –

您是否在當前體系結構中實現了所需的響應時間？如果是的話，理論上，數據庫不會成爲新架構中的問題。

你能告訴我們關於Node.js服務器設置的更多信息嗎？你在使用連接池嗎？如果是這樣，有多少個連接？你有什麼設置UV_THREADPOOL_SIZE？

您是否考慮過在多個Node.js實例前面放置一個負載均衡器來傳播負載？

來源

2017-08-17 18:01:34

謝謝丹。我能夠在當前體系結構中實現所需的響應時間。所以我也認爲數據庫不是問題。是的，我正在使用池大小爲30的連接池（10-30池大小給出相同的結果）。因爲我對節點不太瞭解，所以對UV_THREADPOOL_SIZE知之甚少，因此我們將對此進行調查。關於LB，問題是最初得到沒有LB的結果，看看節點是否能夠處理它。這是一個現實的目標，我試圖實現或節點本身是不是沒有能力，沒有改變像引入LB等體系結構？ –

Node.js使用線程池進行一些異步IO操作。 node-oracledb使用這個線程池很多。 UV_THREADPOOL_SIZE是用於設置池中線程數的環境變量。缺省值是4，因爲現在大多數CPU都有4個內核。但是，如果您保留默認值，那麼最多可以同時連接4個連接。嘗試將其設置爲30，即池中連接的數量，然後查看它的效果。請記住，更多並不總是更好，所以嘗試不同的設置。 –

您可能會仔細閱讀討論UV_THREADPOOL_SIZE的手冊https://github.com/oracle/node-oracledb/blob/v1.13.1/doc/api.md#numberofthreads，並檢查其他調整技巧。 –

負載測試下節點Js響應時間減少

回答

相關問題