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
-->
