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