php-doc-ru/features/persistent-connections.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- EN-Revision: 0799f7789c50a11b746ad713cc8787e4b04dd926 Maintainer: shein Status: ready -->
<!-- Reviewed: no -->
<chapter xml:id="features.persistent-connections" xmlns="http://docbook.org/ns/docbook">
  <title>Постоянные соединения с базами данных</title>

  <simpara>
   Постоянные соединения представляют собой связи с базами данных,
   которые не закрываются при завершении скрипта. При получении запроса
   на постоянное соединение PHP вначале проверяет, имеется ли
   идентичное постоянное соединение (которое было открыто при предыдущих
   обращениях) и, если таковое было найдено, использует его.
   В случае, если идентичного соединения нет, PHP создаёт новое. Под
   "идентичным" подразумевается соединение, открытое на том же хосте с
   таким же именем пользователя и паролем (если они указаны).
  </simpara>
  <simpara>
   Та часть разработчиков, которая не имеет чёткого представления о том,
   как работает веб-сервер и как распределяется нагрузка, могут получить
   ошибочное представление о том, чем на самом деле являются постоянные
   соединения. В частности, постоянные соединения <emphasis>не</emphasis>
   предоставляют возможность открывать 'пользовательские сессии' в том же
   самом соединении, они <emphasis>не</emphasis> предоставляют возможность
   организовывать более эффективные транзакции, также они не предоставляют
   множества других полезных возможностей. Фактически, постоянные соединения
   не предоставляют <emphasis>никакой</emphasis> функциональности, которая
   была бы невозможна в непостоянных аналогичных соединениях.
  </simpara>
  <simpara>
   Почему?
  </simpara>
  <simpara>
   Это зависит от того, как происходит взаимодействие с веб-сервером. Существует
   три основных способа использования PHP сервером для генерации веб-страниц.
  </simpara>
  <simpara>
   Первый способ заключается в том, чтобы использовать PHP как CGI-обёртку.
   При этом PHP-интерпретатор создаётся и уничтожается при каждом
   обращении к странице (PHP-скрипту). Поскольку интерпретатор
   уничтожается после каждого запроса к серверу, все используемые им ресурсы
   (в том числе и соединение с базой данных) закрываются. Следовательно,
   в этом случае вы не получите ничего от использования постоянных соединений -
   их просто нет.
  </simpara>
  <simpara>
   Второй, и наиболее популярный способ - использовать PHP как модуль
   в сервере, который использует несколько процессов. В число таких серверов
   сейчас входит только Apache. В таком случае, можно выделить один процесс
   (родительский), который координирует работу всех остальных процессов
   (дочерних), которые фактически и выполняют работу по обслуживанию веб-страниц.
   При каждом обращении клиента к серверу запрос перенаправляется одному из
   дочерних процессов, который в данный момент не занят обслуживанием другого
   клиента. Это означает, что когда тот же самый клиент выполняет повторный
   запрос к серверу, он может быть обработан другим дочерним процессом, отличным
   от того, который был при первом обращении. После открытия постоянного
   соединения каждая последующая страница, требующая соединения с базой данных,
   может использовать уже установленное ранее соединение с SQL-сервером.
  </simpara>
  <simpara>
   Третий способ - использовать PHP в качестве плагина в многопоточном
   веб-сервере. В настоящее время в PHP реализована поддержка ISAPI,
   WSAPI, и NSAPI (для Windows-платформ), которые позволяют
   подключать PHP к таким многопоточным серверам, как Netscape FastTrack
   (iPlanet), Microsoft's Internet Information  Server (IIS) и
   O'Reilly WebSite Pro. В этом случае поведение PHP полностью аналогично
   рассмотренной ранее модели с использованием нескольких процессов.
  </simpara>
  <simpara>
   Если постоянные соединения не предоставляют никакой дополнительной функциональности,
   чем же они тогда так хороши?
  </simpara>
  <simpara>
   Ответ содержится в повышении эффективности. Постоянные соединения
   полезны в том случае, если при открытии большого количества SQL-соединений
   возникает ощутимая нагрузка на сервер. То, насколько велика эта нагрузка,
   зависит от многих факторов. Например, от того, какая именно база данных
   используется, находится ли она на том же компьютере что и ваш веб-сервер,
   насколько загружена машина, на которой установлен SQL-сервер, и так далее.
   В случае, если затраты на установку соединения велики, постоянные соединения
   могут вам существенно помочь. Они позволяют дочернему процессу на
   протяжении всего жизненного цикла использовать одно и то же соединение
   вместо того, чтобы создавать его при обработке каждой страницы,
   которая взаимодействует с SQL-сервером. Это означает, что каждый дочерний
   процесс, открывший постоянное соединение, будет иметь своё собственное
   соединение с сервером. Например, если у вас запущено 20 дочерних процессов,
   которые выполнили скрипт, использовавший постоянное соединение с SQL-сервером,
   вы получите 20 различных соединений с SQL-сервером, по одному на каждый дочерний
   процесс.
  </simpara>
  <simpara>
   Следует заметить, что этот подход имеет некоторые недостатки: если
   вы используете базу данных с ограниченным количеством возможных
   подключений, оно может быть превышено количеством запрашиваемых
   дочерними процессами постоянных соединений. Например, если ваша база
   данных позволяет 16 одновременных соединений, и во время нагрузки
   на сервер 17 дочерних процессов попробуют открыть соединение, одна из
   попыток потерпит неудачу. Если в вашем коде содержатся ошибки, не позволяющие
   закрывать соединение (например, бесконечные циклы), база данных с
   32 одновременными подключениями вскоре может оказаться заблокированной.
   Информацию о том, как обрабатывать открытые и неиспользуемые соединения, вы можете
   найти в документации к вашей базе данных.
  </simpara>
  <warning>
   <simpara>
    Есть ещё два дополнительных предостережения, которые следует
    помнить при работе с постоянными соединениями. В случае, если скрипт
    блокирует таблицу и по каким-либо причинам не может её освободить,
    при использовании постоянного соединения все последующие скрипты,
    которые используют это соединение будут блокированы бесконечно
    долго и могут потребовать рестарта веб-сервера или сервера баз данных.
    Второе предостережение заключается в том, что открытые транзакции,
    если они не были закрыты до завершения работы скрипта, будут продолжены
    в следующем скрипте, использующем это же постоянное соединение.
    Исходя из этого, вы можете использовать функцию
    <function>register_shutdown_function</function> для указания простой функции,
    которая снимает блокировку таблиц или отката ваших транзакций.
    Ещё лучше избежать этих проблем полностью, не используя постоянные
    соединения в скриптах, которые используют блокировку таблиц или транзакции
    (при этом вы всё ещё можете использовать их где-то в другом месте).
   </simpara>
  </warning>
  <simpara>
   Важное резюме. Постоянные соединения были созданы для точного отображения
   обыкновенных соединений. Это означает, что у вас <emphasis>всегда</emphasis>
   есть возможность заменить все постоянные соединения непостоянными, и это
   никак не отразится на поведении скрипта. Такая замена <emphasis>может</emphasis>
   повлиять (и, наверное, повлияет) на эффективность работы скрипта, но
   никак не на его поведение.
  </simpara>
  <para>
   Смотрите также <function>ibase_pconnect</function>, <function>ociplogon</function>,
   <function>odbc_pconnect</function>, <function>oci_pconnect</function>,
   <function>pfsockopen</function> и <function>pg_pconnect</function>.
  </para>
 </chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->