Conexiones Persistentes a Bases de Datos

Las conexiones persistentes son enlaces que no se cierran cuando la ejecución del script termina. Cuando una conexión persistente es solicitada, PHP chequea si ya existe una conexión persistente idéntica (que fuera abierta antes) - y si existe, la usa. Si no existe, crea el enlace. Una conexión "Idéntica" es una conexión que fue abierta por el mismo host, con el mismo usuario y el mismo password (donde sea aplicable).

Las personas que no estan completamente familiarizadas con como trabajan los web servers y la distribución de carga podrían equivocarse en usar conexiones persistentes para lo que no son. En particular, no le da la habilidad de abrir "sesiones de usuario" en el mismo enlace, no le da la habilidad de construir una transacción eficiente, pero no hacen muchas otras cosas más. De hecho, para ser extremadamente claros acerca de esto, las conexiones persistentes no dan cualquier otra funcionalidad que no fuera posible hacerse con sus hermanas no-persistentes.

¿Por qué?

Esto tiene que ver con la forma en que los web servers trabajan. Hay 3 formas en las cuales el web server puede generar paginas web usando PHP.

El primer método es usar PHP como una "capa" CGI. Cuando se ejecuta de esta forma, una instancia del interprete PHP es creado y destruido por cada solicitud de la página (para una página PHP) al web server. Porque es destruido después de cada solicitud, cualquier recurso que se necesite (como un enlace a un servidor de base de datos SQL) son cerradas cuando son destruidas. En este caso, no se gana nada intentando usar conexiones persistentes -- simplemente no persisten.

La segunda, y mas popular, es ejecutar PHP como un modulo en un servidor multiproceso, el cual actualmente solo incluye a Apache. Un servidor multiproceso normalmente tiene un proceso (el padre) el cual coordina un grupo de procesos (los hijos) los cuales no trabajan sirviendo páginas web. Cuando una solicitud viene desde el cliente, es manejada por uno de los hijos el cual no este sirviendo a otro cliente. Esto significa que cuando el mismo cliente hace una segunda solicitud al servidor, podría ser servido por un proceso hijo diferente a la primera vez. Cuando se abre una conexión persistente, cada petición siguiente de servicios SQL puede reusar la misma conexión establecida al servidor SQL.

El último método es usar PHP como un plug-in para un servidor web multihilos. Actualmente PHP 4 tiene soporte para ISAPI, WSAPI, y NSAPI (en Windows), los cuales permiten usar PHP como un plug-in multihilo en servidores como Nestcape FastTrack (iPlanet), Microsoft Internet Information Server (IIS), y O'Reilly's WebSite Pro. El comportamiento es esencialmente el mismo para el modelo multiproceso descrito antes.

Si las conexiones persistentes no tienen ninguna funcionalidad adicional, ¿Para que son buenas?

La respuesta es extremadamente simple -- eficiencia. Las conexiones persistentes son buenas si la sobrecarga para crear enlaces al servidor SQL son altas. Que hallan o no sobrecargas depende de muchos factores. Como, cual base de datos se usa, que sea o no la misma computadora en que esta el servidor web, así como la carga de la maquina que tiene el servidor SQL y así por el estilo. Lo esencial es que si la sobrecarga de conexiones es alta, las conexiones persistentes ayudan considerablemente. Podrían causar que los procesos hijos únicamente se conecten una vez en todo lo que duran, en lugar de que se haga cada vez que se procese una página que se conecte a un servidor SQL. Esto significa que por cada hijo que abrió una conexión persistente mantendrá una conexión persistente al servidor. Por ejemplo, si se tienen 20 procesos hijos diferentes que ejecutaran un script que hace una conexión persistente al servidor SQL, se tendrían 20 conexiones diferentes al servidor SQL, una por cada hijo.

Nótese, sin embargo, que esto puede tener algunos inconvenientes si se esta usando una base de datos con un limite de conexiones que sean excedidas por las conexiones persistentes hijas. Si la base de datos tiene un limite de 16 conexiones simultaneas, y en el curso de una sesión ocupada del servidor, 17 hilos intentan conectarse, uno no sera posible de hacerse. Si hay bugs en los scripts los cuales no contemplen los cierres de las conexiones (como un loop infinito), la base de datos con los 16 conexiones podría rápidamente hundida. Chequear la documentación de la base de datos para obtener información de como manejar conexiones abandonadas u ociosas.

Advertencia

Hay un par de advertencias mas que tener en mente cuando se usan conexiones persistentes. Una es que cuando se usan bloqueos de tablas con una conexión persistente, si el script por alguna razón no puede soltar el bloqueo, entonces los scripts subsecuentes que usan la misma conexión serán bloqueadas indefinidamente y podría ser necesario reiniciar el servidor httpd o el servidor de la base de datos. Otra cosa es que cuando se usan transacciones, una transacción bloqueada también podría llevar al siguiente script el cual usa la conexión si la ejecución del script termina antes que el bloqueo lo haga. En ese caso, se puede usar register_shutdown_function() para registrar una función de limpieza para desbloquear las tablas o deshacer la transacción. Mejor aún es evitar este problema por completo no usando conexiones persistentes en scripts los cuales usan bloqueo de tablas o transacciones (se pueden usar en otros lugares).

Un resumen importante. Las conexiones persistentes fueron diseñadas para tener conexiones normales uno a uno. Esto significa siempre que se podría ser capaz de reemplazar conexiones persistentes con conexiones no-persistentes, y no cambiaría la forma en que este se comporte. Esto podría (y probablemente lo hará) cambiar la eficiencia del script, pero no su comportamiento!.

Ver también fbsql_pconnect(), ibase_pconnect(), ifx_pconnect(), ingres_pconnect(), msql_pconnect(), mssql_pconnect(), mysql_pconnect(), ociplogon(), odbc_pconnect(), oci_pconnect(), pfsockopen(), pg_pconnect(), and sybase_pconnect().

add a note add a note

User Contributed Notes 12 notes

up
5
fabio
8 years ago
You can in fact provide a port for the connection, take a look at http://de2.php.net/manual/en/function.mysql-pconnect.php#AEN101879

Just use "hostname:port" for the server address.
up
4
christopher dot jones at oracle dot com
7 years ago
For the oci8 extension it is not true that " [...] when using transactions, a transaction block will also carry over to the next script which uses that connection if script execution ends before the transaction block does.".  The oci8 extension does a rollback at the end scripts using persistent connections, thus ending the transaction.  The rollback also releases locks. However any ALTER SESSION command (e.g. changing the date format) on a persistent connection will be retained over to the next script.
up
3
ambrish at php dot net
4 years ago
In IBM_DB2 extension v1.9.0 or later performs a transaction rollback on persistent connections at the end of a request, thus ending the transaction. This prevents the transaction block from carrying over to the next request which uses that connection if script execution ends before the transaction block does.
up
1
php at alfadog dot net
10 months ago
One additional not regarding odbc_pconnect  and possibly other variations of pconnect:

If the connection encounters an error (bad SQL, incorrect request, etc), that error will return with  be present in odbc_errormsg for every subsequent action on that connection, even if subsequent actions don't cause another error.

For example:

A script connects with odbc_pconnect.
The connection is created on it's first use.
The script calls a query "Select * FROM Table1".
Table1 doesn't exist and odbc_errormsg contains that error.

Later(days, perhaps), a different script is called using the same parameters to odbc_pconnect.
The connection already exists, to it is reused.
The script calls a query "Select * FROM Table0".
The query runs fine, but odbc_errormsg still returns the error about Table1 not existing.

I'm not seeing a way to clear that error using odbc_ functions, so keep your eyes open for this gotcha or use odbc_connect instead.
up
1
RQuadling at GMail dot com
8 years ago
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+).
up
0
ynzhang from lakeheadu canada
5 years ago
It seems that using pg_pconnect() will not persist the temporary views/tables. So if you are trying to create temporary views/tables with the query results and then access them with the next script of the same session, you are out of luck. Those temporary view/tables are gone after each PHP script ended. One way to get around this problem is to create real view/table with session ID as part of the name and record the name&creation time in a common table. Have a garbage collection script to drop the view/table who's session is expired.
up
-1
whatspaz at g NO dot SPAM mail dot c o m
8 years ago
in response to web at nick, have you tried FLUSH PRIVILEGES. this should reload those privileges.
up
-3
Tom
4 years ago
There's a third case for PHP: run on a fastCGI interface. In this case, PHP processes are NOT destroyed after each request, and so persistent connections do persist. Set PHP_FCGI_CHILDREN << mysql's max_connections and you'll be fine.
up
-4
andy at paradigm-reborn dot com
7 years ago
To those using MySQL and finding a lot of leftover sleeping processes, take a look at MySQL's wait_timeout directive. By default it is set to 8 hours, but almost any decent production server will have been lowered to the 60 second range. Even on my testing server, I was having problems with too many connections from leftover persistent connections.
up
-7
jean_christian at myrealbox dot com
12 years ago
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."
up
-7
aaryal at foresightint dot com
10 years ago
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.
up
-13
jorgeleon85 at gmail dot com
3 years ago
I've been looking everywhere for a benchmark or at least comparison of the overhead used by oci_connect and oci_pconnect.
Just saying "oci_connect is slower because the overhead..." is not enough for me. For than I wrote a couple scripts to compare perfomance.
At the end I found out an average of 34% more time using a oci_connect than oci_pconnect, using a query of 50 rows and 100 columns.
Obviously this wasn't a real benchmark however it gives a simple idea of the efficiency of each function.
To Top