之前我們?cè)陧?xiàng)目中引入了數(shù)據(jù)庫(kù)連接池之后,在一定程度上,提升了性能.但是,上次我們只是用20個(gè)并發(fā)量做的測(cè)試,而這顯然太小了.所以,這次我們使用了2000個(gè)并發(fā)量來(lái)進(jìn)行測(cè)試.
上次我們把數(shù)據(jù)庫(kù)連接池的尺寸,設(shè)置成了20.在并發(fā)量為20時(shí),沒(méi)有什么問(wèn)題.然而,一旦到了2000的并發(fā)量,我們從Hibernate的Statistic中就能看到,其中有大量的操作,都卡在了從數(shù)據(jù)庫(kù)連接池請(qǐng)求數(shù)據(jù)庫(kù)連接這里.
然后,我們調(diào)大一點(diǎn)數(shù)據(jù)庫(kù)連接池的尺寸,將它改為200,然后將MySQL的接受的最大連接數(shù)量改為300.這次,性能稍微提升了一些.
我們可以看到,最后的測(cè)試,延遲直接到了30+s.
我們從Hibernate的Statistic中看到,這個(gè)延遲,主要是由execute JDBC Statement造成的.
這就很奇怪.起初以為Hibernate的Statistic中的execute JDBC Statement的時(shí)間是MySQL執(zhí)行相應(yīng)的語(yǔ)句的時(shí)間,以為是高并發(fā)導(dǎo)致服務(wù)器負(fù)載過(guò)大,導(dǎo)致MySQL執(zhí)行過(guò)慢.于是,監(jiān)控一下服務(wù)器的狀態(tài),并打開(kāi)MySQL的慢查詢(xún)?nèi)罩竟δ?將慢查詢(xún)的閾值設(shè)置為1s,然后在執(zhí)行一次測(cè)試,發(fā)現(xiàn)服務(wù)器負(fù)載并不大,也沒(méi)有執(zhí)行的過(guò)慢的操作.
這也證明了Hibernate的Statistic中的execute JDBC Statement的時(shí)間,并不是MySQL中執(zhí)行語(yǔ)句的時(shí)間.
既然不是MySQL的問(wèn)題,那么問(wèn)題應(yīng)該出在Hibernate和MySQL連接的過(guò)程中.于是,我們猜測(cè)是網(wǎng)絡(luò)帶寬的問(wèn)題.懷疑是網(wǎng)絡(luò)擁塞的問(wèn)題,登錄上騰訊云,查看網(wǎng)絡(luò)連接的情況:
從這里,我們能夠看到,出帶寬確實(shí)達(dá)到了達(dá)到了我的服務(wù)器的帶寬,1Mb.
早就想到過(guò),帶寬遲早會(huì)是我們的服務(wù)的瓶頸,只是沒(méi)有想到,這就遇到了.
這個(gè)問(wèn)題,只能通過(guò)增加帶寬來(lái)解決了.
Hibernate的Statistic中的execute JDBC Statement的計(jì)算,應(yīng)該是在連接中執(zhí)行Statement之前,記錄一下時(shí)間,然后執(zhí)行完成后,收到MySQL發(fā)送過(guò)來(lái)的成功的消息之后,在記錄一下時(shí)間,然后取這個(gè)時(shí)間的差值.
