Hibernate/c3p0/MySQL下的網絡延遲

Question

我通過一個具有相當高延遲（〜80ms）但帶寬相對較高的連接來連接到MySQL（InnoDB）數據庫。

我注意到，查詢時間根據查詢的發佈方式而有很大不同。在以下示例中，我正在通過主鍵對單個小行進行查詢。查詢時間爲：

• 命令行客戶端（mysql）：〜160毫秒
• 原始JDBC：〜240毫秒
• 休眠：〜400毫秒（〜0毫秒開始，〜160毫秒獲得，〜240毫秒提交）
• 休眠，L2：〜240毫秒（〜0毫秒開始，〜0毫秒得到，〜240毫秒提交）
• 休眠，C3P0：〜880ms（〜160毫秒開始，〜240ms處得到，〜480ms提交）
• 休眠，L2 + C3P0 ：〜640ms（〜160ms開始，〜0ms得到，〜480ms提交）

（「L2」表示啓用了Hibernate二級緩存，「c3p0」表示c3p0已啓用，「開始」，「獲取」和「提交」是查詢過程中調用的各種子方法的計時）

這些大致是「穩態」結果，所以L2緩存很熱，並且Hibernate啓動時間被忽略。我假設啓用L2緩存時「get」通常是0ms，因爲實際上沒有get。

我的問題是：

• 爲什麼是網絡延遲的所有查詢的如此大的倍數？即使是mysql命令行客戶端似乎也需要2次往返才能進行簡單的查詢。
• 爲什麼所有的JDBC/Hibernate查詢都比命令行客戶端慢得多？即使原始的JDBC客戶端似乎也需要3次往返。
• 爲什麼c3p0似乎會讓一切變得更糟？據我所知，我已經禁用了連接測試，否則可能會解釋這些事情。

Answer 1

我沒有針對您的問題的建議，但有一些調試技術可以幫助您找出發生了什麼事情。如果你可以添加一個連接參數，以連接URL，JDBC驅動程序將記錄基本上都通過線路與時序：

的jdbc：mysql的：//服務器/數據庫profileSQL =真

http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-configuration-properties.html

？

你可以看看這個的另一種方式是通過tcpdump監視你的網絡流量。從Maatkit工具MK-查詢消化可以讀取轉儲輸出，並幫助你找出到底發生了什麼：

http://www.mysqlperformanceblog.com/2009/07/01/gathering-queries-from-a-server-with-maatkit-and-tcpdump/

希望這有助於。

Answer 2

• 如果你使用的彈簧，使用lazydatasource以僅打開連接，一旦你真正使用它
• 嘗試用BoneCP代替C3P0有更好的表現。