Постоянные соединения с базами данных

Что такое постоянные соединения?

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

Нет способа запросить конкретное соединение или гарантировать, что вернётся существующее соединение или совершенно новое (если все существующие соединения заняты или запрос обслуживается другим процессом, у которого есть отдельный пул соединений).

Поэтому постоянные соединения PHP нельзя использовать, например, для:

назначения определённой сессии базы данных конкретному веб-пользователю
создания крупной транзакции, охватывающей несколько запросов
инициализации запроса для одного запроса и собирания результатов по другому

Постоянные соединения не предоставляют никакой функциональности, которая была бы недоступна при использовании непостоянных соединений.

Веб-запросы

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

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

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

Замечание:
Чтобы проверить, какой метод используют веб-запросы, посмотрите значение «Server API» в выводе функции phpinfo() или значение константы PHP_SAPI, полученное из веб-запроса.

Если API сервера является «Apache 2 Handler» или «FPM/FastCGI», то постоянные соединения будут использоваться для всех запросов, обслуживаемых одним и тем же рабочим процессом. Для любого другого значения постоянные соединения не будут сохраняться после каждого запроса.

Процессы командной строки

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

Зачем их использовать?

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

Возможные недостатки: ограничения подключения

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

Постоянные соединения обычно увеличивают количество соединений, открытых в любой момент времени, поскольку неактивные рабочие процессы по-прежнему удерживают соединения для предыдущих запросов, которые они обслуживали. Если для обработки потока запросов запускается большое количество рабочих процессов, открытые ими соединения остаются открытыми до тех пор, пока рабочий процесс не будет завершён или сервер базы данных не закроет соединение.

Убедитесь, что максимальное количество подключений, разрешённое сервером базы данных, превышает максимальное количество рабочих процессов веб-запросов (плюс любое другое использование, такое как задания Cron или административные подключения).

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

Возможные недостатки: поддержание состояния соединения

Некоторые модули баз данных выполняют автоматическую очистку при повторном использовании соединения; другие оставляют эту задачу на усмотрение разработчика приложения. В зависимости от выбранного модуля базы данных и конструкции приложения перед завершением работы скрипта может потребоваться ручная очистка. К изменениям, которые могут привести к неожиданному состоянию соединений, относятся:

Выбранная / базовая база данных
Блокировка таблиц
Незавершённые транзакции
Временные таблицы
Настройки или функции, специфичные для подключения, такие как профилирование

Блокировки таблиц и транзакции, которые не очищаются или не закрываются, могут привести к бесконечной блокировке других запросов и/или к неожиданным изменениям при повторном использовании соединения.

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

Если временные таблицы не очищаются, последующие запросы не смогут воссоздать ту же таблицу.

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

Заключительные слова

Учитывая их поведение и потенциальные недостатки, описанные выше, не следует использовать постоянные соединения без тщательного обдумывания. Их не следует использовать без внесения дополнительных изменений в приложение и тщательной настройки сервера базы данных и веб-сервера и/или PHP-FPM.

Рассмотрите альтернативные решения, такие как исследование и устранение причин накладных расходов на создание соединений (например, отключение обратного DNS-поиска на сервере базы данных) или использование специальных прокси-серверов для объединения соединений.

Для веб API с большим объёмом данных рассмотрите возможность использования альтернативных сред выполнения или серверов приложений с длительным временем работы.