1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- EN-Revision: 1.18 Maintainer: cortesi Status: ready -->
<chapter id="features.persistent-connections">
<title>Connessioni Persistenti ai Database</title>
<simpara>
Connessioni persistenti sono collegamenti SQL che non vengono chiusi quando
l'esecusione di uno script viene terminata. Quando richiesta una connessione
persistente, PHP controlla se esiste gi una identica connessione persistente
(che rimasta aperta da prima) - e se esiste, la
usa. Se non esiste, crea il collegamento. Una connessione 'identica'
una connessione aperta verso lo stesso host, con
lo stesso username e la stessa password (dove applicabile).
</simpara>
<note>
<para>
Ci sono altre estensioni che permettono di usare connessioni persistenti, ad
esempio l'<link linkend="ref.imap">estensione IMAP</link>.
</para>
</note>
<simpara>
Chi non ha molta familiarit con il modo in cui lavorano i server web
e di come essi distribuiscano il carico potrebbero confondere le connessioni permanenti per ci
che esse non sono. In particolare, <emphasis>non</emphasis> danno
la possibilit di aprire 'sessioni utente' sullo stesso collegamento SQL,
<emphasis>non</emphasis> danno la possibilit di gestire una transazione in
maniera efficiente e sopratutto non fanno molte altre
cose. Infatti, per essere molto chiari su questo punto,
le connessioni persistenti non hanno <emphasis>nessuna</emphasis>
funzionali che non era disponibile con le loro omonime
non-persistenti.
</simpara>
<simpara>
Perch?
</simpara>
<simpara>
Questo ha a che fare con il modo in cui i server web operano. Ci sono tre modi
in cui un server web pu utilizzare PHP per generare le pagine web.
</simpara>
<simpara>
Il primo metodo ` quello di usare il PHP come un "wrapper" (involucro) CGI. Quando viene
eseguito in questa modalit, per ogni pagina che viene richiesta al server web
che contenga del codice PHP, viene creata e, alla fine dell'esecuzione, distrutta,
una istanza dell'interprete PHP.
Poiché viene distrutta alla fine di ogni richiesta, qualunque risorsa
abbia acquisito (come ad esempio un collegamento ad un server di database SQL) verr
anch'essa distrutta. In questo caso, non vi nessun guadagno nell'usare
le connessioni persistenti -- semplicemente esse non persistono.
</simpara>
<simpara>
Il secondo, e più popolare, metodo quello di eseguire il programma PHP come modulo in un
server web multiprocesso, cosa che attualmente include solo Apache. Un
server multiprocesso ha tipicamente un processo (il padre) che
coordina un insieme di processi (i suoi figli) che sono quelli che
generano le pagine web. Quando arriva una richiesta da parte di un
client, questa passata ad uno dei figli che in quel momento
non gi occupato a servire un altro client. Questo significa che quando lo stesso client effettua
una seconda richiesta al server, esso potr essere servito da un diverso processo
figlio rispetto a quello della prima volta. In questa situazione, usare una
connessione persistente, permette di stabilire una e una sola connessione
al database SQL per ogni processo figlio, poiché ciascun
processo figlio necessita di collegarsi al database SQL solo la
prima volta che richiama una pagina che ne fa uso. Quando viene richamata
un'altra pagina che necessita di una connessione al server SQL, essa pu
riutilizzare la connessione che lo stesso processo figlio aveva
stabilito in precedenza.
</simpara>
<simpara>
L'ultimo metodo quello di usare il PHP come una plug-in per un server web
multithread. Attualmente PHP 4 supporta ISAPI, WSAPI e NSAPI (su piattaforma
Windows), i quali permettono di usare PHP come una plug-in sui server web multithread
come FastTrack (iPlanet) di Netscape, Internet Information Server (IIS) di Microsoft e
WebSite Pro di O'Reilly. Il comportamento essenzialmente
lo stesso che si ha nel modello multiprocesso descritto prima. Si noti che
il supporto SAPI non disponibile in PHP 3.
</simpara>
<simpara>
Se le connessioni persistenti non hanno nessuna funzionalit aggiuntiva, perch´
usarle?
</simpara>
<simpara>
La risposta, in questo caso estremamente semplice: efficienza. Le connessioni
persistenti sono utili se il carico di lavoro necessario per aprire una connessione al server SQL
alto. Che il carico sia molto alto o meno dipende
da molti fattori. Quali, il tipo di database che si utilizza, il fatto che
esso si trovi sulla stessa macchina sulla quale si trova il server web, quanto
carico di lavoro ha la macchina sulla quale si trova il server SQL, e molte altre ragioni. Il
fatto importante che se il carico di lavoro necessario per aprire le connessioni alto, le
connessioni persistenti possono aiutare in maniera considerevole. Fanno in modo che il processo figlio si
colleghi semplicemente una volta durante la sua intera vita, invece di collegarsi ogni volta che
processa una pagina che richiede una connessione al server SQL.
Questo significa che per ogni figlio che ha aperto una connessione
persistente, si avr una nuova connessione persistente aperta verso il
server. Per esempio, se si hanno 20 diversi processi figlio che
eseguono uno script che crea una connessione persistente al server SQL server,
si avranno 20 diverse connessioni al server SQL, una per ogni
figlio.
</simpara>
<simpara>
Si fa notare, tuttavia, che questo pu avere degli svantaggi se si fa uso di
un database che ha un limite al numero di connessioni, minore rispetto al numero delle
connessioni persistenti dei procesi figlio. Se per esempio di usa un database con 16 connessioni simultanee,
e durante un periodo di intensa attivit del web server, 17 processi figlio
cercano di collegarsi, uno non sar in grado di farlo. Se nei vostri script
ci sono bug che non permettono alle connessioni di chiudersi in maniera regolare
(come ad esempio un loop infinito), un database con sole 32 connessioni
diventer rapidamente saturo. Fare riferimento alla documentazione del database per
informazioni su come gestire connessioni abbandonate o inattive.
</simpara>
<warning>
<simpara>
Ci sono un paio di altri caveat da tenere in considerazione quando
si usano le connessioni persistenti. Uno che quando si usa il table
locking su una connessione persistente, se lo script, per una qualunque
ragione non in grado di rimuovere il blocco, allora i successivi script che useranno
la stessa connessione rimarranno bloccati in maniera indefinita e potrebbe essre necessario
riavviare il server httpd o il server database. Un altro che
quando si usano le transazioni, un transaction block verr trasferito
anche allo script successivo che usa la medesima connessione, se lo script in esecuzione
termina prima che sia terminato il transaction block. In entrambi i casi, si pu
usare <function>register_shutdown_function</function> per registrare una
semplice funzione di pulizia per sbloccare le tabelle o effettuare il roll back delle
transaczioni. Sarebbe meglio non dover affrontare il problema, semplicemente non usando
le connessioni persistenti negli script che usano i lock delle tabelle o
le transaczioni (si possono comunque usare in altre situazioni).
</simpara>
</warning>
<simpara>
Sommario importante. Le connessioni persistenti sono state pensate per avere
una mappatura uno-a-uno con le connessioni di tipo normale. Ci significa che si
dovrebbe <emphasis>sempre</emphasis> essere in grado di cambiare una connessione persistente
con una connessione non-persistente, e che questo non dovrebbe cambiare
il modo in cui lo script si comporta. <emphasis>Pu</emphasis> (e
probabilmente succeder) cambiare l'efficienza dello script, ma non il suo
comportamento!
</simpara>
<para>
Vedere anche <function>fbsql_pconnect</function>,
<function>ibase_pconnect</function>, <function>ifx_pconnect</function>,
<function>imap_popen</function>, <function>ingres_pconnect</function>,
<function>msql_pconnect</function>, <function>mssql_pconnect</function>,
<function>mysql_pconnect</function>, <function>OCIPLogon</function>,
<function>odbc_pconnect</function>, <function>Ora_pLogon</function>,
<function>pfsockopen</function>, <function>pg_pconnect</function> e
<function>sybase_pconnect</function>.
</para>
</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
indent-tabs-mode:nil
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
-->
|
