MySQLi постоянные соединения, заполняющие одновременных пользователей

Я работаю в компании, которая недавно обновила код PHP для сайта с vanilla MySQL до MySQLi, чтобы опередить изменения в устаревших версиях.

У нас были некоторые проблемы с MySQL, использующим 64 КБ исходных TCP-портов на уровне сети и перепада. Мы исправили это, включив постоянные соединения.
Однако теперь у нас появилась новая проблема: запросы, которые мы выполняем, не всегда повторно используют существующие соединения и в итоге заполняют все слоты соединений (200).

Настройка, которую мы запускаем, таким образом:

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

У нас есть настраиваемая функция анализа запросов, которая определяет, к какому хосту подключаться, выбирает правильную схему и запускает запрос. Это не проблема, все это прекрасно работает.

Главный сервер БД забивается соединениями, заполняется и затем отказывается от любых новых соединений.

Для каждой загрузки страницы требуется только один вызов mysqli_connect для каждого хоста. Но по какой-то причине соединения никогда не используются повторно. даже обновление одной и той же страницы несколько раз создает новые соединения для каждой загрузки.

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

0

Решение

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

Когда вы просматриваете процессы mysql на сервере db, вы видите много неактивных соединений? Вы можете уменьшить MySQL тайм-аут ожидания значение для сброса бездействующих соединений. Я обычно довольно агрессивен в этой настройке (30 секунд) и прилично масштабирую системы (1 миллион просмотров страниц в день).

Чтобы действительно опередить изменение амортизации, вы должны рассмотреть возможность перехода на PDO. Бесстыдная вилка: я написал мой собственный класс БД который управляет соединениями, соединяется по требованию или переподключается по мере необходимости. Это позволяет очень низкие настройки времени ожидания, не беспокоясь о потерянных соединениях.

0

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector