問題描述

試驗的邏輯比較簡單, 就是Node訪問數據庫查詢數據, SQL語句的執(zhí)行時間在2秒左右, 我用JMeter進行多線程測試(5線程),按照預想的結果(根據Node非堵塞特性), 應該是5線程同時在2秒返回結果, 但是結果是這樣的:

按照結果來看, Node成串行執(zhí)行了, 這和預想的結果完成不一致啊, 哪位能解釋一下

代碼:

app.get(’/’, function (req, res) { var now = +(new Date()) connection.query(’select count(*) from ACTIVITY group by name’, function (err, result, fields) {var curr = +(new Date())var tmp = ’耗時:’ + (curr - now)console.log(tmp)res.send(tmp) })})

注: 不是數據庫處理的問題, 因為我用兩臺不同的機器, 執(zhí)行相同的SQL語句, 時間都2秒

以下為補充

按照@邊城的原因是多條SQL語句用的同一個connection, 現在代碼已修改, 使用的是數據庫連接池, 執(zhí)行結果如下圖:

代碼如下:

app.get(’/’, function (req, res) { var now = +(new Date()) pool.getConnection(function (err, conn) {console.log(’--連接池連接成功!’ + +(new Date()))conn.query(’select count(*) from ACTIVITY group by name’, function (err, result, fields) { var curr = +(new Date()) var tmp = ’耗時:’ + (curr - now) console.log(tmp) res.send(tmp)}) })})

這樣的結果和預想就比較一致了, 5線程同時查詢, 都是在4s+時間返回, 壓力上去了, 查詢時間自然會長, 經測試, 當線程改成2時, 返回的時間在2s+, 和預期也一致!

問題解答

時間起始是 query 之前，結束是 query 完成，所以每個時間是 query 運行的時間，

Node 是異步了，但是你用的是同一個 connection，connection 本身是不是需要排隊呢？據我所知，多數數據庫在同一個 connection 中執(zhí)行的 SQL 都是排隊挨個進行的……多個 connection 之間可能會并行。