Như với tất cả những thứ liên quan đến hiệu suất, câu trả lời là:nó phụ thuộc. Cụ thể, nó phụ thuộc vào chính xác cách bạn đang sử dụng trình điều khiển.
Chi phí tương tác giao dịch với cơ sở dữ liệu được chia thành:chi phí phức tạp mã, chi phí giao tiếp, xử lý sql và I / O đĩa.
Chi phí giao tiếp hơi khác nhau giữa trường hợp XA và không phải XA. Tất cả những điều khác đều bình đẳng, một giao dịch XA mang thêm một chút chi phí ở đây vì nó yêu cầu nhiều chuyến đi khứ hồi hơn đến db. Đối với giao dịch không phải XA trong chế độ cam kết thủ công, chi phí ít nhất là hai lệnh gọi:(các) hoạt động sql và cam kết. Trong trường hợp XA, nó bắt đầu, (các) hoạt động sql, kết thúc, chuẩn bị và cam kết. Đối với trường hợp sử dụng cụ thể của bạn sẽ tự động tối ưu hóa để bắt đầu, (các) hoạt động sql, kết thúc, chuẩn bị. Không phải tất cả các cuộc gọi đều có giá như nhau:dữ liệu được di chuyển trong tập kết quả thường sẽ chiếm ưu thế. Trong mạng LAN, chi phí cho các chuyến đi khứ hồi bổ sung thường không đáng kể.
Tuy nhiên, lưu ý rằng có một số vấn đề thú vị đang rình rập chờ đợi những người không cẩn thận. Ví dụ:một số trình điều khiển không hỗ trợ bộ nhớ đệm câu lệnh đã chuẩn bị sẵn trong chế độ XA, có nghĩa là việc sử dụng XA mang thêm chi phí phân tích lại SQL trên mỗi cuộc gọi hoặc yêu cầu bạn sử dụng nhóm câu lệnh riêng biệt trên đầu trình điều khiển. Trong khi về chủ đề nhóm, việc gộp các kết nối XA một cách chính xác sẽ phức tạp hơn một chút so với việc gộp các kết nối không phải XA, vì vậy tùy thuộc vào việc triển khai nhóm kết nối, bạn cũng có thể thấy một chút ảnh hưởng ở đó. Một số khuôn khổ ORM đặc biệt dễ bị ảnh hưởng bởi chi phí tổng hợp kết nối nếu chúng sử dụng bản phát hành kết nối tích cực và yêu cầu lại trong phạm vi giao dịch. Nếu có thể, hãy định cấu hình để lấy và giữ một kết nối trong suốt thời gian tồn tại của tx thay vì nhấn nhóm nhiều lần.
Với lưu ý đã đề cập trước đây về việc lưu vào bộ nhớ đệm của các câu lệnh đã chuẩn bị, không có sự khác biệt trọng yếu về chi phí xử lý sql giữa XA và không phải XA tx. Tuy nhiên, có một sự khác biệt nhỏ đối với việc sử dụng tài nguyên trên máy chủ db:trong một số trường hợp, máy chủ có thể giải phóng tài nguyên sớm hơn trong trường hợp không phải XA. Tuy nhiên, các giao dịch thường đủ ngắn nên đây không phải là một vấn đề đáng cân nhắc.
Bây giờ chúng ta xem xét chi phí I / O đĩa. Ở đây, chúng tôi quan tâm đến I / O thỉnh thoảng được giao thức XA thực hiện hơn là SQL được sử dụng cho logic nghiệp vụ, vì giao thức sau không thay đổi trong cả hai trường hợp. Đối với các giao dịch chỉ đọc, tình huống rất đơn giản:một người quản lý db và tx hợp lý sẽ không thực hiện bất kỳ ghi nhật ký nào, vì vậy không có chi phí. Đối với các trường hợp ghi, điều tương tự cũng đúng khi db là tài nguyên duy nhất liên quan, do tối ưu hóa cam kết một giai đoạn của XA. Đối với trường hợp 2PC, mỗi máy chủ db hoặc trình quản lý tài nguyên khác cần hai đĩa ghi thay vì ghi đĩa được sử dụng trong các trường hợp không phải XA và trình quản lý tx cũng cần hai đĩa. Nhờ tốc độ lưu trữ ổ đĩa chậm, đây là nguồn chi phí hiệu suất chiếm ưu thế trong XA so với không XA.
Một số đoạn trở lại tôi đã đề cập đến độ phức tạp của mã. XA yêu cầu thực thi mã nhiều hơn một chút so với không XA. Trong hầu hết các trường hợp, sự phức tạp được chôn vùi trong trình quản lý giao dịch, mặc dù tất nhiên bạn có thể điều khiển XA trực tiếp nếu muốn. Chi phí chủ yếu là nhỏ, tùy thuộc vào các cảnh báo đã được đề cập. Trừ khi bạn đang sử dụng trình quản lý giao dịch đặc biệt kém, trong trường hợp đó bạn có thể gặp sự cố. Trường hợp chỉ đọc đặc biệt thú vị - các nhà cung cấp trình quản lý giao dịch thường đặt nỗ lực tối ưu hóa của họ vào mã I / O đĩa, trong khi tranh chấp về khóa là một vấn đề quan trọng hơn đối với các trường hợp sử dụng chỉ đọc, đặc biệt là trên các hệ thống đồng thời cao.
Cũng lưu ý rằng độ phức tạp của mã trong trình quản lý tx là một cái gì đó phức tạp trong các kiến trúc có máy chủ ứng dụng hoặc nhà cung cấp trình quản lý giao dịch tiêu chuẩn khác, vì chúng thường sử dụng nhiều mã giống nhau cho điều phối giao dịch XA và không phải XA. Trong các trường hợp không phải XA, để bỏ lỡ hoàn toàn trình quản lý tx, bạn thường phải yêu cầu máy chủ / khuôn khổ ứng dụng coi kết nối là không giao dịch và sau đó thúc đẩy cam kết trực tiếp bằng JDBC.
Vì vậy, bản tóm tắt là: Chi phí cho các truy vấn sql của bạn sẽ chi phối thời gian giao dịch chỉ đọc bất kể lựa chọn XA / không XA , trừ khi bạn làm rối một thứ gì đó trong cấu hình hoặc thực hiện các thao tác sql đặc biệt nhỏ nhặt trong mỗi lần tx, thì dấu hiệu sau là dấu hiệu logic kinh doanh của bạn có thể sử dụng một số cơ cấu lại để thay đổi tỷ lệ chi phí quản lý tx thành logic kinh doanh trong mỗi lần tx.
Đối với các trường hợp chỉ đọc, do đó, lời khuyên bất khả tri giao thức giao dịch thông thường được áp dụng:hãy xem xét bộ đệm ẩn mức thứ hai nhận biết giao dịch trong giải pháp ORM thay vì nhấn DB mỗi lần. Nếu không, hãy điều chỉnh sql, sau đó tăng bộ đệm đệm của db cho đến khi bạn thấy tỷ lệ truy cập 90% + hoặc bạn sử dụng tối đa các khe cắm RAM của máy chủ, tùy điều kiện nào đến trước. Chỉ lo lắng về XA so với non-XA khi bạn đã làm điều đó và thấy mọi thứ vẫn còn quá chậm.
