slawek Fri Nov 2 18:29:28 2001 EDT
Added files:
/phpdoc/pl/features persistent-connections.xml
Log:
Finished translation
Index: phpdoc/pl/features/persistent-connections.xml
+++ phpdoc/pl/features/persistent-connections.xml
<?xml encoding="iso-8859-1"?>
<!-- $Revision: 1.1 $ -->
<chapter id="features.persistent-connections">
<title>Stałe połączenia z bazami danych</title>
<simpara>
Stałe połączenia (persistent connections) to połączenia, które nie są
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.
</simpara>
<simpara>
Ludzie niezbyt dobrze znający zasady działania serwerów mogą czasem
brać stałe połączenia za coś, czym te nie są. Stałe połączenia
<emphasis>nie</emphasis> stwarzają możliwości otwarcia połączenia dla
konkretnego użytkonika, <emphasis>nie</emphasis> pozwalają na skuteczne
stworzenie systemu transakcji, i nie robią wielu innych rzeczy.
Powiedzmy to jasno, stałe połączenia nie oferują <emphasis>nic</emphasis>
ponad to, co robią 'zwykłe' połączenia.
</simpara>
<simpara>
Dlaczego?
</simpara>
<simpara>
Jest to związane z zasadą działania serwerów. Są trzy sposoby na
które serwer może wykorzystac PHP do generowania stron.
</simpara>
<simpara>
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) są tracone. W tym przypadku
używanie stałych połączeń nie przynosi korzyści, one po prostu nie są stałe.
</simpara>
<simpara>
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.
</simpara>
<simpara>
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 są obsługiwane
przez PHP 3.
</simpara>
<simpara>
Skoro stałe połączenia nie dostarczają większej funkcjonalności, do czego
mogą być przydatne?
</simpara>
<simpara>
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.
</simpara>
<simpara>
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 32 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.
</simpara>
<simpara>
Ważne podsumowanie. Stałe połączenia zostały zaprojektowane tak, by
odpowiadać zwykłym połączeniom. Oznacza to, że <emphasis>zawsze</emphasis>
możesz zastąpić stałe połączenia zwykłymi i nie zmieni to zachowania
skryptu. Natomiast <emphasis>może</emphasis> zmienić (i pewnie zmieni)
jego wydajność!
</simpara>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"../../manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->
