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()_
Zona Clientes
Entrar
