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().