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

eduardcapell Tue Aug 30 01:44:11 2005 EDT Added files: /phpdoc-ca/features persistent-connections.xml Log:

http://cvs.php.net/co.php/phpdoc-ca/features/persistent-connections.xml?r=1.1&p=1 Index: phpdoc-ca/features/persistent-connections.xml +++ phpdoc-ca/features/persistent-connections.xml <?xml version="1.0" encoding="iso-8859-1"?> <!-- $Revision: 1.1 $ --> <!-- EN-Revision: 1.24 Maintainer: eduardcapell Status: ready --> <chapter id="features.persistent-connections"> <title>Connexions Persistents a Bases de Dades</title> <simpara> Les connexions persistents són enllaços que no es tanquen quan finalitza l'execució d'una seqüència. Quan se sol·licita una connexió persistent, el PHP comprova si ja hi ha una connexió persistent idèntica (que ha quedat oberta amb anterioritat) - i si existeix, la utilitza. Si no existeix, crea l'enllaç. Una connexió 'idèntica' és una connexió que ha estat oberta contra la mateix servidor, amb el mateix usuari i la mateixa contrassenya. </simpara> <simpara> Els qui no coneixen bé la manera en què els servidors web funcionen i distribueixen la càrrega poden confondre això de les connexions persistents. En particular, les connexions persistents <emphasis>no</emphasis> donen la possibilitat d'obrir "sessions d'usuari" en el mateix enllaç, tampoc <emphasis>no</emphasis> donen la possibilitat de construir transaccions de manera eficient, i no fan moltes d'altres coses. De fet, per tal que quedi ben clar, les connexions persistents no us donen <emphasis>cap</emphasis> funcionalitat que no fos possible amb els seus germans no-persistents. </simpara> <simpara> Per què? </simpara> <simpara> Té a veure amb la manera de funcionar dels servidors web. Hi ha tres maneres en què el servidor web pot utilitzar el PHP per tal de generar pàgines web. </simpara> <simpara> El primer mètode és el d'utilitzar el PHP com un "embolcall" CGI. Quan s'executa així, una instància de l'intèrpret de PHP es crea i destrueix per cada petició de pàgines PHP al servidor. Com que es destrueix després de cada petició, qualsevol recurs que pugui adquirir (per exemple, enllaços a servidors de bases de dades SQL) també es tanquen en el moment de la destrucció. En aquest cas, no es guanya res amb l'ús de les connexions persistents -- no persistiran. </simpara> <simpara> El segon mètode, segurament el més popular, és l'execució del PHP com a mòdul en un servidor web multiprocés, i això actualment només inclou l'Apache. Un servidor multiprocés normalment té un procés (el pare) que coordina un conjunt de processos (fills) que són els qui realment serveixen les pàgines web. Quan arriba una petició d'un client, aquesta es delega a un procés fill que estigui lliure. Això vol dir que quan el mateix client fa una segona petició al servidor, aquesta pot ser servida per un procés fill diferent del que ha servit la petició anterior. Quan s'obre una connexió persistent, cada pàgina subsegüent que sol·liciti serveis SQL pot reutilitzar la mateixa connexió establerta amb el servidor SQL. </simpara> <simpara> El darrer mètode és l'ús del PHP com un connector per un servidor web multifil. Actualment el PHP 4 dóna suport a ISAPI, WSAPI, i NSAPI (en Windows), i tots ells permeten que el PHP s'usi com un connector en servidors multifil com ara Netscape FastTrack (iPlanet), Internet Information Server (IIS) de Microsoft, i WebSite Pro d'O'Reilly. El comportament és bàsicament el mateix que en el model multiprocés que s'ha descrit abans. Observeu que el suport SAPI no està disponible en PHP 3. </simpara> <simpara> Si les connexions persistents no donen funcionalitats addicionals, per a què serveixen? </simpara> <simpara> La resposta és ben senzilla -- eficiència. Les connexions persistents són útils si el cost de crear un enllaç al servidor SQL és alt. Si aquest cost és o no és alt depèn de molts factors. Per exemple, quin tipus de base de dades estem tractant, si el servidor és a la mateixa màquina que el servidor web, si el servidor de bases de dades està molt o poc carregat, etc. En definitiva, si el coste de la connexió és alt, les connexions persistents poden ser d'una ajuda considerable. Poden fer que un procés fill només es connection una sola vegada en tota la seva vida, enlloc de connectar-se cada vegada que es processa una pàgina que requereix connexió amb el servidor SQL. Això vol dir que per cada fill que ha obert una connexió persistent tindrà la seva pròpia connexió persistent amb el servidor. Per exemple, si teniu que 20 processos fills diferents han executat una seqüència que obria una connexió persistent a la base de dades, tindreu 20 connexions diferents al servidor SQL, una per cada fill. </simpara> <simpara> Observeu, però, que això pot tenir els seus desavantatges, si utilitzeu una base de dades amb límits al nombre de connexions que poden ser excedits per connexions persistents dels processos fills. Si teniu una base de dades amb un límit de 16 connexions simultànies, i en el curs d'una sessió pesada, hi ha 17 processos fills que intenten connectar-s'hi, un no podrà fer-ho. Si hi ha errors en les vostres seqüències que no permeten que les connexions es tanquin mai (bucles infinits, per exemple), la base de dades amb només 16 connexions disponibles aviat s'esgotarà. Comproveu la documentació del servidor de base de dades per conèixer com es gestionen les sessions abandonades o inactives. </simpara> <warning> <simpara> Hi ha un parell de perills addicionals que cal recordar quan s'utilitzen les connexions persistents. Un és el del bloqueig de taules en connexions persistents, ja que si la seqüència, per la raó que sigui, no pot alliberar el bloqueig, les següents seqüències que utilitzin la mateixa connexió es bloquejaran indefinidament i pot ser que calgui reiniciar el servidor web o el servidor de base de dades. Un altre perill és el de l'ús de les transaccions, ja que el bloqueig d'aquestes també se'l trobaran les següents seqüències que utilitzin la connexió. En tots dos casos, és útil la funció <function>register_shutdown_function</function> per tal de registrar una funció ben senzilla que faci neteja i desbloquegi les taules o tiri enrere les transaccions. Encara millor, eviteu el problema i no utilizeu connexions persistents en seqüències que fan servir bloquejos de taules o transaccions, penseu que podeu utilitzar connexions persistents en la resta de casos. </simpara> </warning> <simpara> Un resum important. Les connexions persistents es van dissenyar per tal de tenir una correlació 1 a 1 amb les connexions normals. Això vol dir que <emphasis>sempre</emphasis> hauríeu de poder substituir una connexió persistent per una de no persistent, i no canviarà res de la manera en què s'executa la vostra seqüència. <emphasis>Podria</emphasis> (i segurament serà així) canviar l'eficiència de la seqüència, però no el seu comportament! </simpara> <para> Vegeu també les funcions <function>fbsql_pconnect</function>, <function>ibase_pconnect</function>, <function>ifx_pconnect</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>, i <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 -->