Задержка с удаленной базой данных. Можно ли уменьшить пинг?
Есть нагруженный проект, в среднем 22к запрсов в сек., работает на одной вм в Яндексе, в докер контейнерах. Пришла пора выносить бд на отдельную вм. Вынесли, начались тормоза. В ходе тестов поняли что тормозит сеть.
Пинг на ВМ между php и mysql, порядка 0.04-0.07мс.
Пинг между ВМ php -> удаленная бд, порядка 0.5-0.8мс По дефолту без нагрузки, в 10 раз больше. С нагрузкой подрастает до 2мс, при очень большой нагрузке до 5мс. Это не устраивает.
В общем, можно как-то сохранить пинг в районе 0.1мс ?
Как я понимаю если все это развернуть на выделенном сервере, в несколько вм, то проблема исчезнет. Но это дорого.
Возможно использовать балансировщик ?
Хотелось бы понять куда копать, что почитать? Как-то не гуглится тема, статей про highload масса, но они не совсем про это. Возможно посоветуете литературу.
Тестируется это все дело через яндекс танк, закрались сомнения что танк огромную нагрузку на сеть делает. Т.к. стремимся к 22к запросов к бд. Соответственно кидаем это на 10 страниц, получаем 22к запроса, но при этом огромная нагрузка на сеть, в десятки раз больше чем на проде. Получаем пинг в 2-5мс, все тормозит. Даже если так только на тестовом стенде. Пинг, без нагрузки, 0.5-0.7 все равно много. На странице в среднем 200 запросов к бд, без кэша будет больше. Получаем плюс ~100мс, к загрузке страницы.
Судя по всему, у вас большой проект, вы можете обратиться к Яндексу с таким вопросом.
Скорее всего, самым эффективным решением будет поместить базу в локальную сеть с вашими контейнерами, чтобы они общались между собой не выходя за рамки дата-центра. Не уверен, как это устроено у Облака. Опять же, лучше купить себе тариф поддержки и такие архитектурные решения напрямую с Яндексом обсуждать.
Ping между New-York и Los-Angelos составляет примерно 70мс. Тоесть у вас еще очень даже неплохие показатели времени. У вас работала база внутри докера. Вот и пускай там работает всегда. У вас архитектура такая. Вы разрабатывали и тестировали исходя из таких вот условий.
Возвращайте все взад как было.
И вам надо думать над архитектурой. Что у вас в запросах. Подумайте над когерентными запросами. Например с одной страницы с одно пользователя будет прилетать все время 3 типа запроса. В одном и том-же порядке. Попробуйте их объединить в батч. Оформить как хранимую функцию и получать сразу все 3 ответа за 1 раз. Тоесть у вас вместо трёх блокирующих TTFB будет один TTFB.
Попробуйте кешировать данные через nginx. В большинстве случаев кеширование является спасением для таких вот нагруженных систем. Кеширование - это компромисс. Какие-то данные будут стареть в кеше. Это расплата.
Вы проверяли время выполнения запросов и увидели что оно увеличилось?
Я совсем не уверен что различия в пинге имеют значение. (Кстати о пинге - проверил сейчас в Амазоне - 0.2 мс)
Апликация и база в одной сети? Какие ресурсы у базы старой и новой?
Да, суммарное время запросов на страницу, как раз увеличилось на ~50-100мс.
Все в одной подсети. Ресурсов у бд чуть по меньше, но там с запасом. Не упирается в ресурсы вм.
Вроде бы пинг незначительный, но видимо сказывается. Опыт переноса на удаленную бд, как бы есть, но не с такой нагрузкой. Обычно это никак не заметно, если проект небольшой.
kazuhira_0x94,
"Вроде бы пинг незначительный, но видимо сказывается. " - по-моему, нет. Что-то другое.
Проверьте время запросов sql против старой и новой базы.
Простой
Средний
Простой
