Jakie są wady korzystania z trwałego połączenia w PDO

W odpowiedzi na powyższy problem Karola,

From: http://www.php.net/manual/en/mysqli.quickstart.connections.php -

Powszechnym narzekaniem na trwałe połączenia jest to, że ich stan nie jest resetowany przed ponownym użyciem. Na przykład otwarte i niedokończone transakcje nie są automatycznie wycofywane. Ale również zmiany autoryzacji, które miały miejsce w czasie między wprowadzeniem połączenia do puli a jego ponownym użyciem, nie są odzwierciedlane. Może to być postrzegane jako niepożądane efekt uboczny. Wręcz przeciwnie, nazwa persistent może być rozumiana jako obietnica, że państwo jest wytrwałe.

Rozszerzenie mysqli obsługuje zarówno interpretacje trwałego połączenia: stan utrzymany, jak i reset stanu przed ponownym użyciem. Domyślną wartością jest reset. Przed ponownym użyciem trwałego połączenia, rozszerzenie mysqli domyślnie wywołuje mysqli_change_user(), aby zresetować stan. Trwałe połączenie wydaje się użytkownikowi tak, jakby zostało właśnie otwarte. Nie ma artefaktów z poprzednich zastosowań widoczne.

Funkcja mysqli_change_user() jest kosztowną operacją. Aby uzyskać najlepszą wydajność, użytkownicy mogą chcieć przekompilować rozszerzenie z ustawioną flagą compile MYSQLI_NO_CHANGE_USER_ON_PCONNECT.

Użytkownikowi pozostaje wybór pomiędzy bezpiecznym zachowaniem a najlepszą wydajnością. Oba są ważnymi celami optymalizacji. Dla ułatwienia użytkowania, bezpieczne zachowanie zostało ustawione jako domyślne kosztem maksymalnej wydajności.

W moich testach miałem czas połączenia ponad sekundę do mojego localhost, więc zakładając, że powinienem użyć stałego połączenia. Kolejne testy wykazały, że był to problem z "localhost":

Wyniki testu w sekundach (mierzone przez PHP microtime):

• hosted web: connectDB: 0.0038912296295166
• localhost: connectDB: 1.0214691162109 (w ciągu jednej sekundy: nie używaj localhost!)
• 127.0.0.1: connectDB: 0.00097203254699707

Co ciekawe: następujące kod jest tak samo szybki jak użycie 127.0.0.1:

$host = gethostbyname('localhost');
// echo "<p>$host</p>";
$db = new PDO("mysql:host=$host;dbname=" . DATABASE . ';charset=utf8', $username, $password,
    array(PDO::ATTR_EMULATE_PREPARES => false,
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));

Trwałe połączenia są dobrym pomysłem tylko wtedy, gdy połączenie z bazą danych zajmuje (stosunkowo) dużo czasu. W dzisiejszych czasach prawie nigdy tak nie jest. Największą wadą trwałych połączeń jest to, że ogranicza liczbę użytkowników, których możesz przeglądać witrynę: jeśli MySQL jest skonfigurowany tak, aby zezwalał tylko na równoczesne połączenia 10 naraz, to gdy 11 osoba próbuje przeglądać witrynę, nie będzie dla nich działać.

PDO nie zarządza trwałością. Sterownik MySQL tak. Informatyka ponownie wykorzystuje połączenia, gdy a) są one dostępne I host/użytkownik/hasło/baza danych pasują. Jeśli jakakolwiek zmiana nie spowoduje ponownego użycia połączenia. Najlepszym efektem sieciowym jest to, że te połączenia, które masz, będą uruchamiane i zatrzymywane tak często, ponieważ masz różnych użytkowników na stronie, a ich trwałe działanie nie robi nic dobrego.

Kluczową rzeczą do zrozumienia na temat trwałych połączeń jest to, że nie należy ich używać w większości aplikacji internetowych. Brzmią kusząco, ale są niebezpieczne i bezużyteczne.

Jestem pewien, że są inne wątki na ten temat, ale trwałe połączenie jest niebezpieczne, ponieważ utrzymuje się między żądaniami. Jeśli na przykład zablokujesz stół podczas żądania, a następnie nie uda Ci się go odblokować, stół pozostanie zablokowany na czas nieokreślony. Trwałe połączenia są również praktycznie bezużyteczne w 99% Twoich aplikacji, ponieważ nie masz możliwości sprawdzenia, czy to samo połączenie będzie używane między różnymi żądaniami. Każdy wątek www będzie miał to własny zestaw trwałych połączeń i nie masz możliwości kontrolowania, który wątek będzie obsługiwał które żądania.

Proceduralna biblioteka mysql PHP, posiada funkcję, dzięki której kolejne wywołania do mysql_connect zwrócą ten sam link, zamiast otworzyć inne połączenie (jak można się spodziewać). Nie ma to nic wspólnego z trwałymi połączeniami i jest specyficzne dla biblioteki mysql. PDO nie wykazuje takiego zachowania

Resource Link: link

In Ogólne możesz użyć tego jako szorstki "zestaw reguł"::

tak , użyj trwałych połączeń, Jeśli:

• do bazy danych ma dostęp tylko kilka aplikacji/użytkowników, tj. nie spowoduje to 200 otwartych (ale prawdopodobnie bezczynnych) połączeń, ponieważ na tym samym hoście jest 200 różnych użytkowników.

• Baza danych działa na innym serwerze, do którego uzyskujesz dostęp sieć

• (jedna) aplikacja uzyskuje dostęp do bazy danych bardzo często

nie, nie używaj trwałych połączeń, Jeśli:

• Twoja aplikacja musi uzyskać dostęp do bazy danych tylko 100 razy na godzinę.

• Masz wiele, wiele webserverów, którzy mają dostęp do jednego serwera bazy danych

Używanie trwałych połączeń jest znacznie szybsze, zwłaszcza jeśli uzyskujesz dostęp do bazy danych przez sieć. To nie ma tak wielkiej różnicy, czy baza danych jest uruchomiona na tym samym komputerze, ale nadal jest trochę szybciej. Jednak - jak sama nazwa mówi-połączenie jest trwałe, tzn. pozostaje otwarte, nawet jeśli nie jest używane.

Problem polega na tym, że w" domyślnej konfiguracji "MySQL zezwala tylko na 1000 równoległych "otwartych kanałów". Po tym, nowe połączenia są odrzucane(można dostosować to ustawienie). Więc jeśli masz-powiedzmy-20 Webserverów z każdym klientem 100, a każdy z nich ma tylko jeden dostęp do strony na godzinę, prosta matematyka pokaże ci, że będziesz potrzebował 2000 równoległych połączenia z bazą danych. To nie zadziała.

Ergo: używaj go tylko do aplikacji z dużą ilością zapytań.

Trwałe połączenia powinny zwiększyć wydajność. Nie zgadzam się z twierdzeniem, że należy "unikać" uporu..

Wygląda na to, że powyższe skargi są napędzane przez kogoś, kto używa tabel MyIASM i hakuje we własnych wersjach transakcji poprzez chwytanie blokad tabel.. Oczywiście, że tak! Użyj metody beginTransaction () PDO i przenieś swoje tabele do InnoDB..

Wydaje mi się, że stałe połączenie zjadłoby więcej zasobów systemowych. Może trywialna kwota, ale i tak...

Wyjaśnieniem używania trwałych połączeń jest oczywiście zmniejszenie ilości połączeń, które są dość kosztowne, pomimo faktu, że są one znacznie szybsze z MySQL w porównaniu do innych baz danych.

Pierwszy problem z trwałymi połączeniami...

Jeśli tworzysz 1000 połączeń na sekundę, zwykle nie upewniasz się, że pozostają otwarte przez bardzo długi czas, ale system operacyjny tak. Oparte na protokole TCP / IP porty nie mogą być natychmiast przetwarzane i również trzeba zainwestować chwilę w" FIN " etapie czekając, zanim mogą być poddane recyklingowi.

Drugi problem... korzystanie z wielu połączeń serwera MySQL.

Wiele osób po prostu nie zdaje sobie sprawy, że jesteś w stanie zwiększyć zmienną *max_connections* i uzyskać ponad 100 jednoczesnych połączeń z MySQL inni zostali pokonani przez starsze problemy z Linuksem z niemożnością przekazania więcej niż 1024 połączeń z MySQL.

Pozwala teraz rozmawiać o tym, dlaczego trwałe połączenia zostały wyłączone w mysqli przedłużenie. Pomimo faktu, że można nadużywać trwałych połączeń i uzyskać słabą wydajność, co nie było głównym powodem. Faktycznym powodem jest-można uzyskać o wiele więcej problemów z nim.

Trwałe połączenia były wprowadzane do PHP przez cały czas MySQL 3.22/3.23, gdy MySQL nie był tak trudny, co oznacza, że można było łatwo przetwarzać połączenia bez żadnych problemów. W późniejszych wersjach pojawiało się jednak wiele problemów – w przypadku recyclingu połączenia, które nie transakcje, które wpadasz w kłopoty. Jeśli odzyskasz połączenia z niestandardowymi konfiguracjami zestawów znaków, ponownie jesteś w niebezpieczeństwie, a także prawdopodobnie zmienisz zmienne w danej sesji.

Problem z używaniem trwałych połączeń polega na tym, że nie skaluje się tak dobrze. Dla tych, którzy mają podłączonych 5000 osób, potrzebujesz 5000 trwałych połączeń. Aby uzyskać wymóg wytrwałości, możesz mieć możliwość obsługi 10000 osób z podobną ilością połączeń ponieważ są w stanie dzielić się indywidualnymi połączeniami, gdy nie są z nimi.

Zastanawiałem się tylko, czy rozwiązaniem częściowym byłoby mieć pulę zastosowań - raz połączenia. Możesz poświęcić czas na tworzenie puli połączeń, gdy system jest w niskim zużyciu, do limitu, rozdać je i zabić, gdy ukończą lub przekroczą limit czasu. W tle tworzysz nowe połączenia, gdy są one podejmowane. W najgorszym przypadku powinno to być tak powolne, jak tworzenie połączenia bez puli, zakładając, że ustanowienie połączenia jest czynnikiem ograniczającym?