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).
Nota:
Ci sono altre estensioni che permettono di usare connessioni persistenti, ad
esempio l'estensione IMAP.
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, non danno
la possibilit� di aprire 'sessioni utente' sullo stesso collegamento SQL,
non 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 nessuna
funzionali� che non era disponibile con le loro omonime
non-persistenti.
Perch�?
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.
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.
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.
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.
Se le connessioni persistenti non hanno nessuna funzionalit� aggiuntiva, perch�
usarle?
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.
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.
| Attenzione |
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 register_shutdown_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).
|
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 sempre 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. Pu� (e
probabilmente succeder�) cambiare l'efficienza dello script, ma non il suo
comportamento!
Vedere anche fbsql_pconnect(),
ibase_pconnect(), ifx_pconnect(),
imap_popen(), ingres_pconnect(),
msql_pconnect(), mssql_pconnect(),
mysql_pconnect(), OCIPLogon(),
odbc_pconnect(), Ora_pLogon(),
pfsockopen(), pg_pconnect() e
sybase_pconnect().
Connection handling
