問(wèn)題描述

試驗(yàn)的邏輯比較簡(jiǎn)單, 就是Node訪問(wèn)數(shù)據(jù)庫(kù)查詢數(shù)據(jù), SQL語(yǔ)句的執(zhí)行時(shí)間在2秒左右, 我用JMeter進(jìn)行多線程測(cè)試(5線程),按照預(yù)想的結(jié)果(根據(jù)Node非堵塞特性), 應(yīng)該是5線程同時(shí)在2秒返回結(jié)果, 但是結(jié)果是這樣的:

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

代碼:

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 = ’耗時(shí):’ + (curr - now)console.log(tmp)res.send(tmp) })})

注: 不是數(shù)據(jù)庫(kù)處理的問(wèn)題, 因?yàn)槲矣脙膳_(tái)不同的機(jī)器, 執(zhí)行相同的SQL語(yǔ)句, 時(shí)間都2秒

以下為補(bǔ)充

按照@邊城的原因是多條SQL語(yǔ)句用的同一個(gè)connection, 現(xiàn)在代碼已修改, 使用的是數(shù)據(jù)庫(kù)連接池, 執(zhí)行結(jié)果如下圖:

代碼如下:

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 = ’耗時(shí):’ + (curr - now) console.log(tmp) res.send(tmp)}) })})

這樣的結(jié)果和預(yù)想就比較一致了, 5線程同時(shí)查詢, 都是在4s+時(shí)間返回, 壓力上去了, 查詢時(shí)間自然會(huì)長(zhǎng), 經(jīng)測(cè)試, 當(dāng)線程改成2時(shí), 返回的時(shí)間在2s+, 和預(yù)期也一致!

問(wèn)題解答

時(shí)間起始是 query 之前，結(jié)束是 query 完成，所以每個(gè)時(shí)間是 query 運(yùn)行的時(shí)間，

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