XA與非XA JDBC驅動程序的性能？

Question

我們在不需要的情況下使用XA JDBC驅動程序（只讀工作不參與分佈式事務）。

只是想知道是否有任何已知的性能增益需要切換到Non-XA JDBC驅動程序 - 如果沒有，它可能不值得切換？這取決於：我們正在使用MySQL 5.1

Answer 1

與相關的一切事物的表現，答案是

FWIW。具體而言，這取決於你如何使用驅動程序。

與數據庫事務性交互的代價大致分爲：代碼複雜性開銷，通信開銷，sql處理和磁盤I/O。

XA與非XA情況之間的通信開銷略有不同。所有其他條件相同的情況下，XA交易的成本稍高一些，因爲它需要更多的往返數據庫。對於手動提交模式下的非XA事務，成本至少爲兩個調用：sql操作和提交。在XA的情況下，它是開始，SQL操作，結束，準備和提交。對於您的特定用例，它會自動優化以啓動，sql操作，結束，準備。並非所有調用都具有相同的成本：在結果集中移動的數據通常占主導地位。在局域網上，額外往返的成本通常並不顯着。

但請注意，有一些有趣的陷阱潛藏在等待不守規矩的地方。例如，某些驅動程序不支持在XA模式下準備好的語句緩存，這意味着XA使用會帶來在每次調用時重新解析SQL的額外開銷，或者需要您在驅動程序頂部使用單獨的語句緩衝池。雖然就池的話題而言，正確地合併XA連接要比合並非XA連接要複雜一些，因此根據連接池的實現情況，您也可能會看到一些細節。如果某些ORM框架使用主動連接釋放並在事務範圍內重新獲取，則它們特別容易受到連接池開銷的影響。如果可能，請配置爲在tx的生命週期內抓取並保持一個連接，而不是多次敲擊池。

由於前面提到的關於緩存預處理語句的警告，XA和非XA tx之間的SQL處理成本沒有實質性差異。然而，數據庫服務器上的資源使用情況稍有不同：在某些情況下，服務器可能會在非XA情況下儘早釋放資源。然而，交易通常很短，這不是一個重要的考慮因素。

現在我們考慮磁盤I/O開銷。這裏我們關注的是XA協議引起的I/O，而不是用於業務邏輯的SQL，因爲後者在任何情況下都不變。對於只讀事務而言，情況很簡單：明智的db和tx管理器不會執行任何日誌寫入，因此沒有開銷。對於寫入情況，由於XA的一個階段提交優化，數據庫是唯一涉及的資源，情況也是如此。對於2PC的情況，每個數據庫服務器或其他資源管理器需要兩次磁盤寫入，而不是非XA情況下使用的寫入，而tx管理器同樣需要兩次。由於磁盤存儲緩慢，這是XA與非XA性能開銷的主要來源。

後面幾段提到了代碼的複雜性。 XA比非XA需要更多的代碼執行。在大多數情況下，複雜性被埋在交易管理器中，儘管如果您願意，您當然也可以直接驅動XA。成本大多是微不足道的，但須遵守已提及的注意事項。除非您使用特別差的交易管理器，否則您可能會遇到問題。只讀的情況特別有趣 - 事務管理器提供者通常將其優化工作放入磁盤I/O代碼中，而對於只讀用例而言，鎖爭用是一個更重要的問題，特別是在高度併發的系統上。

還要注意，tx管理器中的代碼複雜性在以應用程序服務器或其他標準事務管理器提供程序爲特徵的體系結構中是一種紅字，因爲它們通常對XA和非XA事務協調使用相同的代碼。在非XA情況下，爲了完全錯過tx管理器，通常必須告訴應用程序服務器/框架將連接視爲非事務性，然後使用JDBC直接驅動提交。

所以摘要是：你的SQL查詢的成本是要稱霸只讀交易時間無論XA /非XA選擇的，除非你弄亂的東西在配置上還是做的特別每個tx中的簡單sql操作，後者是您的業務邏輯可能使用某種重構來改變每個tx中tx管理開銷與業務邏輯的比率的一個標誌。

對於只讀情況，通常的事務協議不可知的建議因此適用：在ORM解決方案中考慮事務感知級二級緩存，而不是每次都敲擊數據庫。否則，請調整sql，然後增加數據庫的緩衝區緩存，直到您看到90％的命中率或者您將服務器的RAM插槽中的最大值（以先到者爲準）。一旦你做完了，只需要擔心XA和非XA，發現事情仍然太慢。

Answer 2

簡要解釋一下， XA事務是一個「全局事務」。 非XA交易是「本地交易」。

XA事務涉及協調事務管理器，一個或多個數據庫（或其他資源，如JMS）都參與單個全局事務。 非XA事務沒有事務協調器，並且單個資源本身正在完成其所有事務工作。