Rozdział 21 . Stałe połączenia z bazami danych

Stałe połączenia ( persistent connections ) to połączenia , które nie zamykane po wykonaniu skryptu . Kiedy skrypt próbuje nawiązać stałe połączenie , PHP sprawdza czy istnieje już identyczne połączenie ( otwarte wcześniej ) i jeśli istnieje , używa go . Jeżeli nie , tworzone jest nowe . Połączenie ' identyczne ' to połączenie z tym samym hostem , z taką samą nazwą użytkownika i hasłem .

Notatka : Istnieją także inne moduły udostępniające stałe połączenia , na przykład IMAP .

Ludzie niezbyt dobrze znający zasady działania serwerów mogą czasem brać stałe połączenia za coś , czym te nie . Stałe połączenia nie stwarzają możliwości otwarcia połączenia dla konkretnego użytkonika , nie pozwalają na skuteczne stworzenie systemu transakcji , i nie robią wielu innych rzeczy . Powiedzmy to jasno , stałe połączenia nie oferują nic ponad to , co robią ' zwykłe ' połączenia .

Dlaczego ?

Jest to związane z zasadą działania serwerów . trzy sposoby na które serwer może wykorzystac PHP do generowania stron .

Pierwsza metoda to wykorzystanie PHP jako " wrappera " CGI . Przy wywołaniu skryptu każdorazowo uruchamiany i niszczony jest egzamplarz PHP . Jako , że jest on niszczony po każdym wywołaniu , wszystkie zasoby przez niego posiadane ( na przykład połączenia z bazą danych ) tracone . W tym przypadku używanie stałych połączeń nie przynosi korzyści , one po prostu nie stałe .

Druga , najpopularniejsza metoda , to uruchomienie PHP jako modułu w wieloprocesowym serwerze , co obecnie dotyczy jedynie serwera Apache . Serwer wieloprocesowy zwykle uruchamia jeden proces ( rodzica) , który koordynuje inne procesy (potomne ) zajmujące się dostarczaniem stron . Kiedy nadchodzi żądanie od klienta , jest ono przekazywane jednemu z procesów potomnych , który w danym momencie nie obsługuje innego klienta . Oznacza to , że gdy ten sam klient wyśle do serwera kolejne żądanie , może zostać obsłużony przez inny proces niż za pierwszym razem . Stałe połączenie w tym przypadku oznacza , że każdy proces potomny ustanawia połączenie z serwerem SQL przy pierwszym wywołaniu strony , która takiego połączenia używa . Jeśli inna strona potrzebuje połączenia z serwerem SQL , może wykorzystać połączenie , które dany proces ustanowił wcześniej .

Ustatnia metoda to wykorzystanie PHP jako wtyczki ( plug-in ) do serwera wielowątkowego . Obecnie PHP4 zawiera obsługę mechanizmów ISAPI , WSAPI i NSAPI ( w Windows) , które umożliwiają uruchomienie PHP jako wtyczki do wielowątkowych serwerów takich jak Netscape FastTrack (iPlanet) , Microsoft Internet Information Server (IIS ) i O 'Reilly WebSite Pro . Zachowanie PHP jest zasadniczo takie samo jak w przypadku opisanego wcześniej modelu wieloprocesowego . Mechanizmy SAPI nie obsługiwane przez PHP 3 .

Skoro stałe połączenia nie dostarczają większej funkcjonalności , do czego mogą być przydatne ?

Odpowiedź jest niezwykle prosta - - wydajność . Stałe połączenia sprawdzają się w przypadku , gdy koszt nawiązania połączenia z SQL serwerem jest wysoki . To czy koszt jest duży czy nie zależy od wielu czynników . Na przykład od typu bazy danych , od tego czy znajduje się ona na tym samym serwerze , od obciążenia maszyny , która obsługuje serwer SQL , itd . Jeśli zatem koszt połączenia jest wysoki , stałe połączenia znacznie pomagają . Sprawiają , że proces potomny łączy się z serwerem SQL tylko raz podczas swojego życia , zamiast otwierać połączenie za każdym razem gdy zażąda tego skrypt . Oznacza to , że każdy proces potomny , który nawiązał stałe połączenie , będzie posiadał własne połączenie z serwerem bazy danych . Dla przykładu , jeżeli 20 procesów potomnych uruchomi skrypt , który ustanowi stałe połączenie z serwerem SQL , będziesz mieć 20 różnych połączeń z serwerem , jedno na każdy proces .

Trzeba jednak zauważyć , że może to mieć swoje ujemne strony w przypadku , gdy limit połączeń do bazy danych zostanie przekroczony przez stałe połączenia z procesów potomnych . Jeśli twoja baza danych posiada limit szesnastu jednoczesnych połączeń , a w danej chwili obciążenie jest wysokie , siedemnasty proces nie będzie mógł się połączyć . Jeśli twoje skrypty zawierają błędy , które nie pozwalają zamknąć połączeń ( na przykłąd nieskończone pętle ) , baza danych z limitem 16 połączeń może szybko zostać zapchana . Poszukaj w dokumentacji swojej bazy danych w jaki sposób radzi sobie ona z porzuconymi lub bezczynnymi połączeniami .

Ostrzeżenie

Istnieje kilka zagrożeń , które należy brać pod uwagę decydując się na używanie stałych połączeń . Jednym z nich jest sytuacja , w której skrypt blokujący tabelę , z jakiegokolwiek powodu nie może zdjąć blokady . Wtedy kolejne skrypty korzystające z tego samego połączenia będą zablokowane i może zajść potrzeba ponownego uruchomienia serwera httpd lub serwera bazy danych . Kolejne zagrożenie dotyczy transakcji . Jeśli skrypt używający transakcji zakończy działanie przed zakończeniem bloku transakcji , to zostanie on ( blok ) przeniesiony do następnego skryptu . W obu przypadkach można użyć register_shutdown_function( ) , aby zarejestrować funkcję porządkującą , która odblokuje tabele lub wycofa transakcje . Najlepiej jednak jest zrezygnować ze stałych połączeń w skryptach używających blokowania tabel lub transakcji .

Istotne podsumowanie . Stałe połączenia zostały zaprojektowane tak , by odpowiadać zwykłym połączeniom . Oznacza to , że zawsze możesz zastąpić stałe połączenia zwykłymi i nie zmieni to zachowania skryptu . Natomiast może zmienić ( i zapewne zmieni ) jego wydajność !

Zobacz także fbsql_pconnect( ) , ibase_pconnect( ) , ifx_pconnect( ) , imap_popen( ) , ingres_pconnect( ) , msql_pconnect( ) , mssql_pconnect( ) , mysql_pconnect( ) , OCIPLogon( ) , odbc_pconnect( ) , Ora_pLogon( ) , pfsockopen( ) , pg_pconnect( ) i sybase_pconnect( ) .