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

Постоянные соединения это SQL-ссылки, которые не закрываются по окончании работы скрипта. Когда постоянное соединение запрашивается, PHP проверяет, имеется ли уже идентичное постоянное соединение (которое осталось открытым после предыдущего запроса) - и, если имеется, использует его. Если не имеется, РНР создаёт ссылку. 'Идентичным' является соединение, которое было открыто с тем же хостом, с тем же username и с тем же password (если имеются).

Примечание: Имеются другие расширения, которые предоставляют постоянные соединения, такие как IMAP.

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

Патщему?

Это зависит от способа работы web-серверов. Есть три способа использования РНР вашим web-сервером для генерации web-страниц.

Первый метод - использование PHP как CGI "wrapper/оболочки". При этом экземпляр PHP-интерпретатора создаётся и разрушается для каждого запроса страницы (PHP-страницы) к вашему web-серверу. Поскольку он уничтожается после выполнения каждого запроса, при этом закрываются все ресурсы, которые он использовал (такие как ссылка на SQL-сервер БД). В этом случае вы ничего не получите от использования постоянных соединений - они просто не существуют.

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

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

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

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

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

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

См. также fbsql_pconnect(), ibase_pconnect(), ifx_pconnect(), imap_popen(), ingres_pconnect(), msql_pconnect(), mssql_pconnect(), mysql_pconnect(), OCIPLogon(), odbc_pconnect(), Ora_pLogon(), pfsockopen(), pg_pconnect() и sybase_pconnect().