2012-03-16 4 views
35

W celu uniknięcia napowietrznej utworzenia nowego połączenia za każdym razem potrzeby zapytań wystrzeliwanych przeciwko MySQL, istnieją dwie możliwości:MySQL - Trwałe połączenie vs zestawianie połączeń

  1. Stałe połączenia, przy czym nowe połączenie jest zażądano sprawdzenia, czy "identyczne" połączenie jest już otwarte, a jeśli tak, użyj go.
  2. Pule połączeń, w których klient utrzymuje pulę połączeń, dzięki czemu każdy wątek, który musi korzystać z połączenia, wyewidencjonuje jeden z puli i po zakończeniu przywróci go do puli.

Tak więc, jeśli mam wielowątkową aplikację serwerową, która ma obsłużyć tysiące żądań na sekundę, a każdy wątek musi wystrzelić zapytanie do bazy danych, to jaka jest lepsza opcja?

Z mojego rozumowania, Dzięki stałym połączeniom wszystkie wątki w mojej aplikacji będą próbowały używać tego samego trwałego połączenia z bazą danych, ponieważ wszystkie używają identycznych połączeń. Jest to jedno połączenie współużytkowane przez wiele wątków aplikacji - w rezultacie żądania będą blokowane wkrótce po stronie bazy danych.

Jeśli korzystam z mechanizmu łączenia połączeń, wszystkie wątki aplikacji będą współużytkować pulę połączeń. Tak więc istnieje mniejsze prawdopodobieństwo żądania zablokowania. Jednak w przypadku łączenia połączeń, czy wątek aplikacji powinien czekać na uzyskanie połączenia z puli, czy powinien mimo to wysłać zapytanie o połączenia w puli i czy kolejkowanie w bazie danych jest możliwe?

Odpowiedz

22

Posiadanie połączeń trwałych nie oznacza, że ​​wszystkie wątki używają tego samego połączenia. Po prostu "mówi", że utrzymujesz połączenie otwarte (w przeciwieństwie do otwierania połączenia za każdym razem, gdy go potrzebujesz). Otwarcie połączenia jest kosztowną operacją, więc - na ogół - starasz się unikać otwierania połączeń częściej niż to konieczne.

Jest to powód, dla którego aplikacje wielowątkowe często korzystają z pul połączeń. Pula zajmuje się otwieraciem i zamykaniem połączeń, a każdy wątek, który wymaga połączenia, żąda jednego z puli. Ważne jest, aby zadbać o to, aby wątek jak najszybciej zwrócił połączenie z pulą, aby inny wątek mógł z niego korzystać.

Jeśli aplikacja ma tylko kilka długich wątków wymagających połączeń, można również otworzyć połączenie dla każdego wątku i pozostawić to otwarte.

Używanie tylko jednego połączenia (zgodnie z opisem) jest równe puli połączeń o maksymalnej wielkości jeden. To będzie prędzej czy później twoje wąskie gardło, ponieważ wszystkie wątki będą musiały poczekać na połączenie. Może to być opcja serializacji operacji na bazie danych (wykonać je w określonej kolejności), chociaż istnieją lepsze opcje w celu zapewnienia serializacji.

+0

W przypadku łączenia połączeń deweloper aplikacji może kontrolować, kiedy i ile połączeń ma być otwieranych/zamykanych. W przypadku MySQL, jak można kontrolować liczbę "identycznych" trwałych połączeń? Czy są jakieś parametry konfiguracyjne serwera dla tego samego? – user1259642

+2

W pulach, z których korzystam, ustaw minimalny i maksymalny rozmiar puli i określ czas bezczynności, po którym połączenie zostanie zamknięte (oraz kilka innych rzeczy). – mrab

15

Jeśli chodzi o pytanie, czy serwer aplikacji powinien czekać na połączenie, odpowiedź brzmi "tak".

Połączenia MySQL są blokowane. Podczas wysyłania żądania z serwera MySQL przez połączenie, połączenie będzie czekać, bezczynnie, do czasu otrzymania odpowiedzi z serwera.

Nie ma możliwości wysłania dwóch żądań na tym samym połączeniu i sprawdzenia, które z nich zwraca się jako pierwsze. Możesz wysłać tylko jedno żądanie naraz.

Zasadniczo pojedynczy wątek w puli połączeń składa się z jednego połączenia po stronie klienta (w twoim przypadku serwer aplikacji jest klientem) i jednego połączenia po stronie serwera (bazy danych).

Twoja aplikacja powinna poczekać na dostępny wątek połączenia z puli, umożliwiając wzrost puli, kiedy jest potrzebna, i zmniejszyć domyślną liczbę wątków, gdy jest mniej zajęty.