eWEEK Labs/PC Labs 可以說是做基準測試的老大了，早在 1993年 10月份他們的姐妹雜誌 PC Magazine 就做過同樣的測試。這次和 PC Magazine 合作測試了五種資料庫在 Java 應用伺服器上的表現，結果顯示 MySQL 最新的 4.0.1 版本效能可以和 Oracle 9i 媲美， 墊低的當然是微軟的 SQL Server 2000 。 測試的這五種資料庫是：IBM 的 DB2 7.2 FixPack 5，微軟的 SQL Server 2000 企業版 SP2， MySQL AB 的 MySQL 4.0.1 Max， Oracle 的 Oracle9i 企業版 9.0.1.1.1 以及 Sybase 的 ASE (Adaptive Server Enterprise) 12.5.0.1。 測試相容性也是基準測試的一個主要目的，所有的資料庫都在同樣的硬體條件下測試： HP NetServer LT 6000r 帶有四顆 700MHz Xeon CPU， 2GB 記憶體以及 24 台 10000 rpm 的 9.1GB Ultra3 SCSI 磁碟，作業系統為 Windows 2000 Advanced Server SP2。 測試的應用程式是一個叫做 Nile 的基於 Web 的書店應用。Nile 採用了 Empirix 公司的測試套件 6.0 ，能載入 50 到 10000 個並發使用者。 測試採用的應用伺服器是 BEA 的 WebLogic 6.1 SP1，並用 JSP 編寫了 Nile 應用。 每種測試回合一個小時產生五萬張訂單，15 萬到 20萬相關的記錄數，我們得到的最好的伸縮性是在兩台 6路 HP NetServer LT 6000r （ 4GB 記憶體，千兆網卡）伺服器上運行6個 WebLogic 常式。HTTP 流量均衡的分配到這六個常式中。 測試的總體結果顯示 Oracle9i 和 MySQL 有最好的效能和伸縮性，但是 9i 僅僅略微比 MySQL 好一些，ASE, DB2, Oracle9i 和 MySQL 到達 550 個並發使用者時已經“力不從心”了，ASE 的效能下降到了每秒 500 個頁面，比 9i 和 MySQL 要低 100 個頁面，DB2 在高負荷情況下，效能下降也很厲害，只有每秒 200 個頁面了。 由於 JDBC 驅動存在問題，SQL Server 在整個測試中都只能達到每秒 200 個頁面。 驅動，記憶體最佳化和資料庫設計問題是影響效能的主要因素，經過手工細調後的效能會和沒有調優的效能差兩倍。 Oracle 和 MySQL 的驅動具有完整的 JDBC 特色和穩定性（MySQL的員工採用了Mark Matthews 編寫的 JDBC 驅動，因為他們沒有自己的 JDBC 驅動程式）。 為各種資料庫找到最好的記憶體配置是一件具有挑戰性的工作，我們在這個問題上花了好幾天。 SQL Server 和 MySQL 的配置最簡單，而 Oracle9i 是最複雜的。 9i 採用了很多獨立的記憶體緩衝，每個資料庫連接需要消耗很大的記憶體（大約 400KB），而 DB2 只需要 177 KB， SQL Server, MySQL 和 ASE 都只需要 50KB 就夠了，結果是 9i 的資料和執行計畫的緩衝就比別的資料庫要小。 MySQL 的高效能源自採用了記憶體內的查詢結果集緩衝，這是 4.0.1 的新特色，我們不採用這個緩衝的話， MySQL 的效能會下降三分之二。另外， MySQL 的員工還根據表的不同採用不同的資料庫引擎。 所有的訂單表採用 MySQL 的 InnoDB 引擎（支援事務，行鎖，多版本同步），目錄和使用者表則不需要事務支援，採用了 MySQL 的輕量的，非事務的 MyISAM 引擎。 MySQL 4.0.1 的新引入的高速查詢緩衝引人注目，其他的資料庫沒有這個特色。如果查詢的文本具有和緩衝中一模一樣的匹配的話，MySQL 能直接從緩衝去資料，而不需要編譯查詢語句，取鎖或者搜尋索引，這項技術在表不被經常更新的情況下十分有用。 微軟的 SQL 2000 雖然在 Java 平台上沒有上好表現，但是當我們用 ASP.Net 重寫基準測試，並採用 IIS 5.0 ，和 OLE DB 串連，得到的結果或許會讓 Bill Gates 鬆口氣，每秒 870 個頁面。 在測試前，我們邀請五家公司派員參與測試，只有 MySQL 和 Sybase 欣然前往，IBM 只是答應通過電子郵件交流，微軟和 Oracle 都拒絕參加。因此他們的資料庫調整都是我們代勞的。 在測試中，我們驚奇的發現驅動程式是問題的最大根源。 在五種被測試的資料庫中，只有 9i 和 MySQL 能連續運行 Nile 8個小時，DB2 的 JDBC 驅動不支援可更新的結果集，因此我們只能開啟所有的結果集（採用 CONCUR_READ_ONLY），採用 SQL update 語句來更新，最終還是通過了 8個小時的穩定性測試。 在採用 Sybase 的 JConnect 5.5 驅動時，我們發現當應用請求的結果集包含雙向遊標時，JConnect 把整個結果集儲存在用戶端的記憶體裡來增加後續遊標的命令處理速度，這項工作在低負荷時還馬馬虎虎，但是當使用者達到上百時，應用伺服器消耗了幾百兆的記憶體。結果不到 8 個小時，我們的 6個 應用伺服器處理序統統掛起了。 為瞭解決這個問題，我們把應用的瀏覽邏輯重新改寫，只採用前向遊標（JConnect 不在用戶端記憶體緩衝），為了保證查閱到前面的圖書，我們需要把相同的查詢運行兩遍，得到圖書的總數然後得到圖書的資料，這樣就影響了 ASE 的效能。 但是，這樣做的結果是 ASE 的能整夜的跑基準測試，用戶端能從 C/S 結構的應用中獲益，但是對於應用伺服器而言，這是一個可憐的選擇。 微軟的 JDBC 設計有缺陷，在 WebLogic 的控制台上我們發現每次 JAVA 虛擬機器作garbage collection，釋放出來的記憶體就少了一些，所以微軟的 JDBC 驅動用不到 8 小時就歇菜了。 （本文翻譯：徐永久，轉載時請務必註明：FreeLAMP.com 徐永久。謝謝！）
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=491321
