Что является недостатками использования постоянного соединения в PDO
В PDO связь может быть установлена персистентное использование PDO::ATTR_PERSISTENT атрибут. Согласно php руководству -
Постоянные соединения не закрываются в конце сценария, но кэшируются и снова используются, когда другой сценарий запрашивает соединение с помощью тех же учетных данных. Кэш постоянного соединения позволяет Вам избегать издержек установления нового соединения каждый раз, когда сценарий должен говорить с базой данных, приводящей к более быстрому веб-приложению.
Руководство также рекомендует не использовать постоянное соединение при использовании PDO драйвер ODBC, потому что это может препятствовать процессу Организации пула подключений ODBC.
Так, по-видимому, кажется, нет никаких недостатков использования постоянного соединения в PDO, кроме последнего случая.как бы то ни было., я хотел бы знать, существуют ли какие-либо другие недостатки использования этого механизма, т.е. ситуации, где этот механизм приводит к снижению производительности или чему-то как этот.
2 ответа
Не забудьте прочитать этот ответ ниже , в котором подробно описаны способы решения проблем, описанных здесь.
Использование PDO имеет те же недостатки, что и любой другой интерфейс базы данных PHP, который выполняет постоянные соединения: если ваш скрипт неожиданно завершается в середине операций с базой данных, следующий запрос, который получает оставшееся соединение, подберет место, где остался мертвый скрипт. выключенный. Соединение остается открытым на уровне диспетчера процессов (Apache для mod_php, текущий процесс FastCGI, если вы используете FastCGI и т. Д.), А не на уровне PHP, и PHP не сообщает родительскому процессу позволить соединению умереть, когда сценарий аварийно завершает работу.
Если мертвый скрипт заблокировал таблицы, эти таблицы будут оставаться заблокированными до тех пор, пока соединение не разорвется или следующий скрипт, который устанавливает соединение, не разблокирует сами таблицы.
Если мертвый скрипт находился в середине транзакции, он может заблокировать множество таблиц до тех пор, пока не сработает таймер взаимоблокировки, и даже тогда таймер взаимоблокировки может уничтожить новый запрос вместо старого запроса, вызывающего проблему. .
Если мертвый сценарий находился в середине транзакции, следующий сценарий, который получит это соединение, также получит состояние транзакции. Очень возможно (в зависимости от дизайна вашего приложения), что следующий скрипт может никогда не попытаться зафиксировать существующую транзакцию, или совершит фиксацию, когда этого не должно быть, или откатится, когда этого не должно было быть.
Это только верхушка айсберга. Все это можно в некоторой степени смягчить, всегда пытаясь очистить после грязного соединения при каждом отдельном запросе сценария, но это может быть проблемой в зависимости от базы данных. Если вы не определили создание подключений к базе данных как , то единственное узкое место в вашем скрипте (это означает, что вы выполнили профилирование кода с помощью xdebug и / или xhprof ]), вам не следует не рассматривать постоянные соединения как решение чего-либо.
Кроме того, большинство современных баз данных (включая PostgreSQL) имеют свои собственные предпочтительные способы выполнения пула соединений, которые не имеют непосредственных недостатков, присущих обычным постоянным соединениям на основе PHP.
Чтобы прояснить ситуацию, мы используем постоянные соединения на моем рабочем месте, но не по выбору.Мы столкнулись с странным поведением подключения, когда первоначальное подключение от нашего сервера приложений к нашему серверу базы данных занимало ровно три секунды, тогда как это должно было занять доли секунды. . Мы думаем, что это ошибка ядра. Мы отказались от попыток устранить его, потому что это произошло случайно и не могло быть воспроизведено по требованию, а у наших внешних ИТ-специалистов не было конкретной возможности отследить это.
Несмотря на это, когда люди на складе обрабатывают несколько сотен поступающих деталей, и каждая часть занимает три с половиной секунды вместо полсекунды, мы должны были принять меры, прежде чем они похитили нас всех и заставили нас помочь им . Итак, мы добавили несколько кусочков в нашу доморощенную чудовищную систему ERP / CRM / CMS и на собственном опыте испытали все ужасы постоянных подключений. Нам потребовалось недель , чтобы отследить все тонкие маленькие проблемы и причудливое поведение, которые, казалось бы, происходили случайно. Оказалось, что те фатальные ошибки, которые случаются раз в неделю, которые наши пользователи старательно выдавливают из нашего приложения, оставляют заблокированные таблицы, прерванные транзакции и другие неприятные шаткие состояния.
В этой рыдающей истории есть смысл: Он сломал то, что мы никогда не ожидали сломать, и все во имя производительности. Компромисс того не стоил, и мы с нетерпением ждем того дня, когда сможем вернуться к нормальному подключению без бунта со стороны наших пользователей.
Мне кажется, постоянное соединение потребляет больше системных ресурсов. Может быть, банальная сумма, но все же ...