cvs: phpdoc /it/features persistent-connections.xml

From:	Simone Cortesi	Date:	Wed, 18 Jul 2001 17:03:18 +0000
Subject:	cvs: phpdoc /it/features persistent-connections.xml
Groups:	php.doc
Request:	Send a blank email to phpdoc+get-969336309@lists.php.net to get a copy of this message

cortesi Wed Jul 18 13:03:18 2001 EDT Modified files: /phpdoc/it/features persistent-connections.xml Log: initial translation Index: phpdoc/it/features/persistent-connections.xml diff -u /dev/null phpdoc/it/features/persistent-connections.xml:1.4 --- /dev/null Wed Jul 18 13:03:18 2001 +++ phpdoc/it/features/persistent-connections.xml Wed Jul 18 13:03:17 2001 @@ -0,0 +1,132 @@ + <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> + <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 &grave; 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 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> + <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> + + </chapter> + + + + +