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

--eduardcapell1125380651
Content-Type: text/plain

eduardcapell		Tue Aug 30 01:44:11 2005 EDT

  Added files:                 
    /phpdoc-ca/features	persistent-connections.xml 
  Log:
  
  
--eduardcapell1125380651
Content-Type: text/plain
Content-Disposition: attachment; filename="eduardcapell-20050830014411.txt"


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

--eduardcapell1125380651--