CapÃtulo 41. Conexiones persistentes a bases de datos

Las conexiones persistentes son enlaces que no se cierran cuando termina la ejecuciÃ³n del archivo de comandos. Cuando se pide una conexiÃ³n persistente, PHP comprueba si hay ya una conexiÃ³n persistente idÃ©ntica (que permanecÃa abierta desde antes) - y si existe, la usa. Si no existe, crea un enlace. Una conexiÃ³n 'idÃ©ntica' es una conexiÃ³n que se abriÃ³ hacia el mismo "host", con el mismo nombre de usuario y la misma contraseÃ±a (donde sea aplicable).

La gente que no estÃ¡ familiarizada con el modo como trabajan y distribuyen la carga los servidores "web" puede confundir que significa conexiones persistentes. En particular, no te dan la habilidad de abrir 'sesiones de usuario' en el mismo enlace, no dan la habilidad de construir una transacciÃ³n de forma eficiente, y no hacen un montÃ³n de otras cosas. De hecho, para ser extremadamente claros sobre el tema las conexiones persistentes no te dan ninguna functionalidad que no fuera posible con sus hermanas no-persistentes.

Â¿Por quÃ©?

Esto tiene que ver con el modo como funcionan los servidores "web". Hay tres modos en que un servidor "web" puede utilizar PHP para generar pÃ¡ginas web.

El primer mÃ©todo es usar PHP como una capa CGI. Cuando corre de este modo, se crea y destruye una instancia del intÃ©rprete PHP por cada pÃ¡gina solicitada (para una pÃ¡gina PHP) a tu servidor. Debido a que se destruye despuÃ©s de cada peticiÃ³n, cualquier recurso que adquiera (como un enlace a un servidor de base de datos SQL) se cierra cuando es destruido. En este caso, no se gana nada si se intentan usar conexiones persistentes, ya que simplemente no persisten.

El segundo, y mÃ¡s popular, mÃ©todo es correr PHP como un mÃ³dulo en un servidor web multiproceso, lo cual actualmente sÃ³lo incluye Apache. Un servidor multiproceso tiene tÃpicamente un proceso (el padre) que coordina un conjunto de procesos (sus hijos) que realmente hacen el trabajo se servir las pÃ¡ginas web. Cuando entra cada peticiÃ³n de un cliente, es entregada a uno de los hijos que no estÃ© ya sirviendo a otro cliente. Esto significa que cuando el mismo cliente hace una segunda petciÃ³n al servidor, puede ser atendido por un proceso hijo distinto del de la primera vez. Lo que una conexiÃ³n persistente hace por ti en este caso es hacerlo de tal modo que cada proceso hijo sÃ³lo necesita conectar a tu SQL server la primera vez que sirve una pÃ¡gina que hace uso de una conexiÃ³n asÃ. Cuando otra pÃ¡gina solicita una conexiÃ³n a SQL server, puede reutilizar la conexiÃ³n que el hijo estableciÃ³ previamente.

El Ãºltimo mÃ©todo es usar PHP como un "plug-in" para un servidor web multihilo. En la actualidad es solamente teÃ³rico -- PHP no funciona aÃºn como "plug-in" para ningÃºn servidor web multihilo. Actualmente PHP 4 soporta ISAPI, WSAPI y NSAPI (en Windows), lo cual permite a PHP ser utilizado como "plug-in" para servidores web multihilo como Netscape FastTrack, Internet Information Server (IIS) de Microsoft, y O'Reilly's WebSite Pro. El comportamiento es exactamente el mismo que para el modelo de multiprocesador descrito anteriormente. Tener en cuanta que el soporte para SAPI no estÃ¡ disponible en PHP 3.

Si las conexiones persistentes no aportan ninguna funcionalidad aÃ±adida, Â¿para quÃ© son buenas?

La respuesta aqui es extremadamente simple -- eficiencia. Las conexiones persistentes son buenas si las cabeceras de control para crear un enlace a tu servidor SQL es alta. Que estas cabeceras sean o no realmente altas depende de muchos factores. Como, quÃ© clase de base de datos es, si esta o no situada en el mismo ordenador que el servidor web, cÃ³mo estÃ¡ de cargada la mÃ¡quina donde se encuentre el servidor SQL, y otras asÃ. El hecho fundamental es que si la cabecera de conexiÃ³n es alta, las conexiones persistentes te ayudan considerablemente . Ellas hacen que el proceso hijo simplemente conecte solamente una vez durante todo su intervalo de vida, en vez de cada vez que procesa una pagina que requiere conectar al servidor SQL. Esto significa que por cada hijo que abriÃ³ una conexiÃ³n persistente tendrÃ¡ su propia conexiÃ³n persistente al servidor. Por ejemplo, si tienes 20 procesos hijos distintos que corran un archivo de comandos que cree una conexiÃ³n persistente a tu servidor SQL, tendrÃas 20 conexiones diferentes a ti servidor SQL, una por cada hijo.

No obstante, hay que tener en cuenta que esto puede tener desventajas si estais utilizando una base de datos con lÃmites de conexiÃ³n, por debajo del numero de procesos hijo con conexiones persistentes. Si tu base de datos tiene un lÃmite de 16 conexiones simultaneas y en el curso de una sesiÃ³n de servidor, 17 procesos hijo intentan conectarse, uno de ellos no podrÃ¡ hacerlo. Si existen errores en los scripts, que no permitan terminar la conexion (p.ej.bucles infinitos), una base de datos con solo 16 conexiones puede ser rÃ¡pidamente hundida. Comprobar la documentacion de vuestra base de datos para obtener informaciÃ³n sobre que hacer con conexiones abandonadas Ã³ libres.

Aviso

Un par de advertencias mÃ¡s a tener en cuenta cuando utiliceis conexiones persistentes. La primera, si utilizais bloqueos en una tabla desde una conexiÃ³n persistente y por cualquier causa el script no puede desbloquear la tabla, todos los scripts posteriores que usen esta conexiÃ³n, quedarÃ¡n bloqueados indefinÃdamente y se requerirÃ¡ que, Ã³ bien el servidor httpd Ã³ la base de datos sean arrancados de nuevo. La segunda, cuando utiliceis transacciones, un bloqueo por transacciÃ³n serÃ¡ heredado por el prÃ³ximo script usando la conexiÃ³n, si la ejecuciÃ³n del primer script termina antes que el bloqueo. en ambos caso podeis utilizar register_shutdown_function() para registrar una funcion simple de limpieza que desbloquee las tablas Ã³ deshaga la transacciÃ³n. Lo mejor para evitar problemas es no usar conexiones persistentes en scripts que usen bloqueos de tablas Ã³ transacciones (para todolo demÃ¡s pueden ser usadas sin problemas)

Un resumen importante. Las conexiones persistentes fueron diseÃ±adas para tener una equivalencia uno-a-uno con las conexiones normales. Eso significa que deberÃais siempre ser capaz de reemplazar las conexiones persistentes por conexiones no persistentes y no cambiarÃ¡ el modo como se comporta el archivo de comandos. Puede cambiar la eficiencia del archivo de comandos (y probablemete lo harÃ¡), Â¡pero no su comportamiento!

Ver tambien fbsql_pconnect(), ibase_pconnect(), ifx_pconnect(), imap_popen(), ingres_pconnect(), msql_pconnect(), mssql_pconnect(), mysql_pconnect(), ociplogon(), odbc_pconnect(), ora_plogon(), pfsockopen(), pg_pconnect() y sybase_pconnect().

add a note User Contributed Notes
Conexiones persistentes a bases de datos

RQuadling at GMail dot com
06-Mar-2006 03:43


If you have multiple databases on the same server AND you are using persistent connections, you MUST prefix all the table names with the specific database name.



Changing the database using the xxx_select_db functions alters the database for the connection for all users who are sharing that connection (assuming PHP is running shared and not CGI/CLI).



If you have 2 databases (live and archive) and your script is talking to both, you cannot use 2 persistent connections and change the database for each one.



Internally, persistent connections are used even if you do not specify that you want to use persistent connections. This is why new_link was added to mysql_connect/mssql_connect (PHPV4.2.0+).

fabio
12-Jan-2006 03:54


You can in fact provide a port for the connection, take a look at http://de2.php.net/manual/en/http://indices.com.es/function.mysql-pconnect.html#AEN101879



Just use "hostname:port" for the server address.

aaryal at foresightint dot com
15-Jan-2004 03:21


this one bit quite a bit of chunk out of my you-know-what. seems like if you're running multiple database servers on the same host (for eg. MySQL on a number of ports) you can't use pconnect since the port number isn't part of the key for database connections. especially if you have the same username and password to connect to all the database servers running on different ports. but then it might be php-MySQL specific. you might get a connection for an entirely different port than the one you asked for.

web at nickSPAMrabinowitz dot com
02-Dec-2003 02:41


This may only pertain to Apache/MySQL:



After several hours of wrestling with MySQL "Access denied" messages, I determined that persistent database connections don't necessarily reflect subsequent privilege changes.



I loaded a PHP script attempting a LOAD DATA statement, and got an "Access denied" error. I granted FILE privileges to the MySQL user, and was able to run LOAD DATA statements from the terminal, but still got "Access denied" from my PHP pages.  When I switched from mysql_pconnect() to mysql_connect(), the problem went away; eventually I restarted apache to kill the persistent connection and switched back to mysql_pconnect(), and now everything works fine.

jean_christian at myrealbox dot com
15-Aug-2002 03:13


If anyone ever wonders why the number of idle db process (open connections) seems to grow even though you are using persistent connections, here's why:



"You are probably using a multi-process web server such as Apache. Since

database connections cannot be shared among different processes a new

one is created if the request happen to come to a different web server

child process."

sebastian at flothow dot de
18-Apr-2000 07:28


Yes, with nonpersistent connections database connections last only while a database-related request is processed, thus reducing the load on the database server.


However, latency will be somewhat higher since a database connection must be opened before a request can be handeled.

add a note