Podobnie jak w przypadku wszystkich rzeczy związanych z wydajnością, odpowiedź brzmi:to zależy. W szczególności zależy to od tego, jak dokładnie używasz sterownika.
Koszt transakcyjnej interakcji z bazą danych dzieli się z grubsza na:koszty związane ze złożonością kodu, koszty komunikacji, przetwarzanie sql i dyskowe operacje wejścia/wyjścia.
Narzut komunikacji różni się nieco między przypadkami XA i innymi niż XA. Wszystko inne jest równe, transakcja XA wiąże się tutaj z nieco wyższym kosztem, ponieważ wymaga więcej podróży w obie strony do bazy danych. W przypadku transakcji innej niż XA w trybie ręcznego zatwierdzania koszt to co najmniej dwa wywołania:operacja(e) sql i zatwierdzenie. W przypadku XA jest to start, operacja(e) sql, zakończenie, przygotowanie i zatwierdzenie. Dla konkretnego przypadku użycia, który automatycznie zoptymalizuje, aby rozpocząć, operacje sql, zakończyć, przygotować. Nie wszystkie połączenia mają taki sam koszt:dane przeniesione w zestawie wyników zwykle będą dominować. W sieci LAN koszt dodatkowych podróży w obie strony zwykle nie jest znaczący.
Zwróć jednak uwagę, że na nieostrożnych czają się kilka interesujących pułapek. Na przykład niektóre sterowniki nie obsługują buforowania przygotowanych instrukcji w trybie XA, co oznacza, że użycie XA wiąże się z dodatkowym obciążeniem polegającym na ponownej analizie SQL przy każdym wywołaniu lub wymaga użycia oddzielnej puli instrukcji na górze sterownika. Jeśli chodzi o pule, prawidłowe tworzenie puli połączeń XA jest nieco bardziej skomplikowane niż pule połączeń innych niż XA, więc w zależności od implementacji puli połączeń możesz również zauważyć niewielki problem. Niektóre struktury ORM są szczególnie podatne na obciążenie puli połączeń, jeśli używają agresywnego zwalniania połączeń i ponownie nabywają dane w zakresie transakcji. Jeśli to możliwe, skonfiguruj tak, aby przechwytywać i utrzymywać połączenie przez cały okres istnienia tx, zamiast wielokrotnie trafiać do puli.
Z zastrzeżeniem wspomnianym wcześniej, dotyczącym buforowania przygotowanych instrukcji, nie ma istotnej różnicy w koszcie obsługi sql między tx XA i innym niż XA. Istnieje jednak niewielka różnica w zużyciu zasobów na serwerze db:w niektórych przypadkach serwer może zwolnić zasoby wcześniej w przypadku innym niż XA. Jednak transakcje są zwykle na tyle krótkie, że nie ma to większego znaczenia.
Teraz rozważymy obciążenie dysku we/wy. Tutaj zajmujemy się I/O wywołanymi protokołem XA, a nie SQL używanym w logice biznesowej, ponieważ ten ostatni pozostaje niezmieniony w obu przypadkach. W przypadku transakcji tylko do odczytu sytuacja jest prosta:rozsądny menedżer db i tx nie wykonuje żadnych zapisów dziennika, więc nie ma narzutu. W przypadku zapisu to samo dotyczy sytuacji, gdy db jest jedynym zaangażowanym zasobem, ze względu na optymalizację zatwierdzania jednofazowego XA. W przypadku 2PC każdy serwer db lub inny menedżer zasobów potrzebuje dwóch zapisów na dysku zamiast tego używanego w przypadkach innych niż XA, a menedżer tx również potrzebuje dwóch. Dzięki powolności pamięci dyskowej jest to dominujące źródło narzutu wydajności w XA w porównaniu z innymi niż XA.
Kilka akapitów wstecz wspomniałem o złożoności kodu. XA wymaga nieco więcej wykonywania kodu niż inne niż XA. W większości przypadków złożoność tkwi w menedżerze transakcji, chociaż oczywiście możesz bezpośrednio sterować XA, jeśli wolisz. Koszt jest w większości trywialny, z zastrzeżeniem wspomnianych już zastrzeżeń. Chyba że używasz szczególnie słabego menedżera transakcji, w którym to przypadku możesz mieć problem. Szczególnie interesujący jest przypadek tylko do odczytu — dostawcy menedżerów transakcji zwykle wkładają swoje wysiłki w optymalizację kodu we/wy dysku, podczas gdy rywalizacja o blokadę jest poważniejszym problemem w przypadkach użycia tylko do odczytu, szczególnie w systemach o dużej współbieżności.
Należy również zauważyć, że złożoność kodu w menedżerze tx jest czymś w rodzaju czerwonego śledzia w architekturach zawierających serwer aplikacji lub innego standardowego dostawcę menedżera transakcji, ponieważ zwykle używają one tego samego kodu do koordynacji transakcji XA i innych niż XA. W przypadkach innych niż XA, aby całkowicie pominąć menedżera tx, zazwyczaj musisz powiedzieć serwerowi aplikacji / frameworkowi, aby traktował połączenie jako nietransakcyjne, a następnie przeprowadzić zatwierdzenie bezpośrednio za pomocą JDBC.
Więc podsumowanie to:Koszt zapytań sql zdominuje czas transakcji tylko do odczytu, niezależnie od wyboru XA/nie XA , chyba że zepsujesz coś w konfiguracji lub nie wykonasz szczególnie trywialnych operacji sql w każdym tx, to ostatnie jest znakiem, że twoja logika biznesowa może prawdopodobnie użyć pewnej restrukturyzacji, aby zmienić stosunek kosztów zarządzania tx do logiki biznesowej w każdym tx.
W przypadkach tylko do odczytu obowiązuje więc zwykła rada dotycząca niezależnego od protokołu transakcji:rozważ pamięć podręczną drugiego poziomu poziomu obsługującą transakcje w rozwiązaniu ORM, zamiast uderzać za każdym razem w DB. Jeśli to się nie uda, dostrój sql, a następnie zwiększ bufor bufora bazy danych, aż zobaczysz 90%+ współczynnik trafień lub maksymalizujesz gniazda pamięci RAM serwera, w zależności od tego, co nastąpi wcześniej. Tylko martw się o XA i inne niż XA, gdy już to zrobisz i stwierdzisz, że wszystko jest nadal zbyt wolne.
