Я использую PHP PDO-уровень для доступа к данным в проекте, и я читал об этом и вижу, что он имеет хорошую врожденную поддержку постоянных соединений с БД. Мне интересно, когда/если я буду использовать их. Могу ли я увидеть преимущества производительности в приложении CRUD-heavy? Есть ли недостатки, которые следует учитывать, возможно, связанные с безопасностью?
Если это важно для вас, я использую MySQL 5.x.
Вы можете использовать это как грубый "набор правил":
YES, используйте постоянные соединения, если:
НЕТ, не используйте постоянные соединения, если:
Использование постоянных подключений значительно быстрее, особенно если вы обращаетесь к базе данных по сети. Это не имеет большого значения, если база данных работает на одной машине, но она все еще немного быстрее. Однако, как говорится в названии, соединение является постоянным, то есть оно остается открытым, даже если оно не используется.
Проблема заключается в том, что в "конфигурации по умолчанию" MySQL допускает только 1000 параллельных "открытых каналов". После этого новые соединения будут отклонены (вы можете настроить эту настройку). Поэтому, если у вас есть - скажем, 20 веб-серверов с каждым 100 Клиентами на них, и каждый из них имеет только один доступ к странице в час, простая математика покажет вам, что вам потребуется 2000 параллельных подключений к базе данных. Это не сработает.
Ergo: используйте его только для приложений с большим количеством запросов.
Короче говоря, мой опыт говорит, что следует избегать постоянных связей, насколько это возможно.
Обратите внимание, что mysql_close - это неоперация (no-op) для соединений, созданных с использованием mysql_pconnect. Это означает, что постоянное соединение не может быть закрыто клиентом по желанию. Такое соединение будет закрыто сервером mysqldb, если с ним не происходит никаких действий в течение времени, превышающего wait_timeout. Если значение wait_timeout большое (скажем, 30 минут), то сервер mysql db может легко достичь предела max_connections. В таком случае mysql db не будет принимать любой запрос на соединение в будущем. Это когда ваш пейджер начинает подавать звуковые сигналы.
Во избежание достижения предела max_connections, использование соединения Persistent требует тщательной балансировки следующих переменных...
Таким образом, pl использовать постоянное соединение после достаточного обдумывания. Возможно, вы не захотите предлагать сложные проблемы во время выполнения за небольшую выгоду, которую вы получаете от постоянного соединения.
Создание соединений с базой данных - довольно дорогостоящая операция. Стойкие соединения - хорошая идея. В мире ASP.Net и Java у нас есть "пул соединений", что примерно одно и тоже, а также хорошая идея.
IMO, реальный ответ на этот вопрос - это то, что лучше всего подходит для вашего приложения. Я бы рекомендовал вам тестировать ваше приложение, используя как постоянные, так и непостоянные соединения.
Maggie Nelson @Объективно ориентированный опубликовал об этом в августе и Роберт Сварттут сделал сопутствующий пост с некоторыми твердыми цифрами. Оба неплохо читаются.
По моему скромному мнению:
При использовании PHP для веб-разработки большая часть вашего соединения будет "жить" только в течение жизни страницы. Постоянное соединение будет стоить вам больших накладных расходов, так как вам придется поместить его в сеанс или что-то в этом роде.
В 99% случаев одно единственное ненасыщенное соединение, которое умирает в конце выполнения страницы, будет работать нормально.
Другие 1% времени, вы, вероятно, не должны использовать PHP для приложения, и нет идеального решения для вас.
Я собирался задать этот же вопрос, но вместо того, чтобы задавать тот же вопрос снова, я просто добавлю некоторую информацию, которую я нашел.
Также стоит отметить, что новое расширение mysqli даже не включает в себя возможность использования постоянных подключений к базе данных.
Я все еще использую настойчивые соединения в настоящий момент, но планирую перейти к ненастоящему в ближайшем будущем.
В общем, вам иногда нужно использовать непостоянные соединения, и хорошо иметь один шаблон для применения к дизайну соединения db (при условии, что существует относительно небольшой потенциал для использования постоянных подключений в вашем контексте.)