MySQLi постоянные соединения, заполняющие одновременных пользователей
Я работаю в компании, которая недавно обновила код PHP для сайта с vanilla MySQL до MySQLi, чтобы опередить изменения в устаревших версиях.
У нас были некоторые проблемы с MySQL, использующим 64 КБ исходных TCP-портов на уровне сети и перепада. Мы исправили это, включив постоянные соединения.
Однако теперь у нас появилась новая проблема: запросы, которые мы выполняем, не всегда повторно используют существующие соединения и в итоге заполняют все слоты соединений (200).
Настройка, которую мы запускаем, таким образом:
У нас есть несколько серверов БД (4 в среде разработчика) с реплицированными таблицами и отдельными базами данных для каждого клиентского сайта, распределенного по серверам (каждый сайт имеет свою собственную схему) для повышения производительности.
У нас есть настраиваемая функция анализа запросов, которая определяет, к какому хосту подключаться, выбирает правильную схему и запускает запрос. Это не проблема, все это прекрасно работает.
Главный сервер БД забивается соединениями, заполняется и затем отказывается от любых новых соединений.
Для каждой загрузки страницы требуется только один вызов mysqli_connect для каждого хоста. Но по какой-то причине соединения никогда не используются повторно. даже обновление одной и той же страницы несколько раз создает новые соединения для каждой загрузки.
Это нормально? Я ожидал бы, что перезагрузка той же страницы и получение тех же данных приведет к повторному использованию спящих соединений, которые были созданы до обновления.
Решение
Да, это нормально. Вы должны прочитать предупреждения о постоянных соединениях. Первый абзац обычно достаточно, чтобы отпугнуть вас. В других языках постоянные соединения работали так, как вы ожидаете.
Когда вы просматриваете процессы mysql на сервере db, вы видите много неактивных соединений? Вы можете уменьшить MySQL тайм-аут ожидания значение для сброса бездействующих соединений. Я обычно довольно агрессивен в этой настройке (30 секунд) и прилично масштабирую системы (1 миллион просмотров страниц в день).
Чтобы действительно опередить изменение амортизации, вы должны рассмотреть возможность перехода на PDO. Бесстыдная вилка: я написал мой собственный класс БД который управляет соединениями, соединяется по требованию или переподключается по мере необходимости. Это позволяет очень низкие настройки времени ожидания, не беспокоясь о потерянных соединениях.
Другие решения
Других решений пока нет …