Глава 41. Постоянные соединения с базами данных

Постоянные соединения представляют собой связи с базами данных, которые не закрываются при завершении скрипта. При получении запроса на постоянное соединение PHP вначале проверяет, имеется ли идентичное постоянное соединение (которое было открыто при предыдущих обращениях) и, если таковое было найдено, использует его. В случае, если идентичного соединения нет, PHP создает новое. Под "идентичным" подразумевается соединение, открытое на тот же хост с таким же именем пользователя и паролем (если они указаны).

Та часть разработчиков, которая не имеет четкого представления о том, как работает веб-сервер и как распределяется нагрузка, могут получить ошибочное представление о том, чем на самом деле являются постоянные соединения. В частности, постоянные соединения не предоставляют возможность открывать 'пользовательские сессии' в том же самом соединении, они не предоставляют возможность организовывать более эффективные транзакции, также они не предоставляют множества других полезных возможностей. Фактически, постоянные соединения не предоставляют никакой функциональности, которая была бы невозможна в непостоянных аналогичных соединениях.

Почему?

Это зависит от того, как происходит взаимодействие с веб-сервером. Существует три основных способа использования PHP сервером для генерации веб-страниц.

Первый способ заключается в том, чтобы использовать PHP как CGI-оболочку. При этом PHP-интерпретатор создается и уничтожается при каждом обращении к странице (PHP-скрипту). Поскольку интерпретатор уничтожается после каждого запроса к серверу, все используемые им ресурсы (в том числе и соединение с базой данных) закрывается. Следовательно, в этом случае вы не получите ничего от использования постоянных соединений - их просто нет.

Второй, и наиболее популярный способ - использовать PHP как модуль в сервере, который использует несколько процессов. В число таких серверов сейчас входит только Apache. В таком случае, можно выделить один процесс (родительский), который координирует работу всех остальных процессов (дочерних), которые фактически и выполняют работу по обслуживанию веб-страниц. При каждом обращении клиента к серверу запрос перенаправляется одному из дочерних процессов, который в данный момент не занят обслуживанием другого клиента. Это означает, что когда тот же самый клиент выполняет повторный запрос к серверу, он может быть обработан другим дочерним процессом, отличным от того, который был при первом обращении. После открытия постоянного соединения каждая последующая страница, требующая соединения с базой данных, может использовать уже установленное ранее соединение с SQL-сервером.

Третий способ - использовать PHP в качестве плугина в многопоточном веб-сервере. В настоящее время в PHP4 реализована поддержка ISAPI, WSAPI, и NSAPI (для Windows-платформ), которые позволяют подключать PHP к таким многопоточным серверам, как Netscape FastTrack (iPlanet), Microsoft's Internet Information Server (IIS) и O'Reilly WebSite Pro. В этом случае поведение PHP полностью аналогично рассмотренной ранее модели с использованием нескольких процессов. Следует заметить, что поддержка SAPI отсутствует в PHP 3.

Если постоянные соединения не предоставляют никакой дополнительной функциональности, чем же они тогда так хороши?

Ответ содержится в повышении эффективности. Постоянные соединения полезны в том случае, если при открытии большого количества SQL-соединений возникает ощутимая нагрузка на сервер. То, насколько велика эта нагрузка, зависит от многих факторов. Например, от того, какая именно база данных используется, находится ли она на том же компьютере что и ваш веб-сервер, насколько загружена машина, на которой установлен SQL-сервер, и так далее. В случае, если затраты на установку соединения велики, постоянные соединения могут вам существенно помочь. Они позволяют дочернему процессу на протяжении всего жизненного цикла использовать одно и то же соединение вместо того, чтобы создавать его при обработке каждой страницы, которая взаимодействует с SQL-сервером. Это означает, что каждый дочерний процесс, открывший постоянное соединение, будет иметь свое собственное соединение с сервером. Например, если у вас запущено 20 дочерних процессов, которые выполнили скрипт, использовавший постоянное соединение с SQL-сервером, вы получите 20 различных соединений с SQL-сервером, по одному на каждый дочерний процесс.

Следует заметить, что этот подход имеет некоторые недостатки: если вы используете базу данных с ограниченным количеством возможных подключений, оно может быть превышено количеством запрашиваемых дочерними процессами постоянных соединений. Например, если ваша база данных позволяет 16 одновременных соединений, и во время нагрузки на сервер 17 дочерних процессов попробуют открыть соединение, одна из попыток потерпит неудачу. Если в вашем коде содержатся ошибки, не позволяющие закрывать соединение (например, бесконечные циклы), база данных с 32 одновременными подключениями вскоре может оказаться заблокированной. Информацию о том, как обрабатывать открытые и неиспользумые соединения, вы можете найти в документации к вашей базе данных

Внимание

Есть еще два дополнительных предостережения, которые следует помнить при работе с постоянными соединениями. В случае, если скрипт блокирует таблицу и по каким-либо причинам не может ее освободить, при использовании постоянного соединения все последующие скрипты, которые используют это соединение будут блокированы бесконечно долго и могут потребовать рестарта веб-сервера или сервера баз данных. Второе предостережение заключается в том, что открытые транзакции, если они не были закрыты до завершения работы скрипта, будут продолжены в следующем скрипте, использующем это же постоянное соединение. Исходя из этого, вы можете использовать функцию register_shutdown_function() для указания простой функции, которая снимает блокировку таблиц или отката ваших транзакций. Еще лучше избежать этих проблем полностью, не используя постоянные соединения в скриптах, которые используют блокировку таблиц или транзакции (при этом вы все еще можете использовать их где-то в другом месте).

Важное резюме. Постоянные соединения были созданы для точного отображения обыкновенных соединений. Это означает, что у вас всегда есть возможность заменить все постоянные соединения непостоянными, и это никак не отразится на поведении скрипта. Такая замена может повлиять (и, наверное, таки повлияет) на эффективность работы скрипта, но никак не на его поведение.

Смотрите также fbsql_pconnect(), ibase_pconnect(), ifx_pconnect(), ingres_pconnect(), msql_pconnect(), mssql_pconnect(), mysql_pconnect(), ociplogon(), odbc_pconnect(), ora_plogon(), pfsockopen(), pg_pconnect(), и sybase_pconnect().



Постоянные соединения с базами данных
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/function.mysql-pconnect.php#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.

<Работа с соединениямиЗащищенный режим>
 Last updated: Mon, 14 Nov 2005