У меня в настоящее время есть один общедоступный эластичный кластер с одним узлом данных (m3.xlarge.elasticsearch), который работает нормально.Я хотел бы перейти от общедоступного домена к домену на основе VPC.
Мне удалось сделать снимок вручную с общедоступной конечной точки и восстановить его до конечной точки VPC.
Пока миграция прошла успешноВ настоящее время я сталкиваюсь с проблемой задержки поиска, в то время как общедоступная конечная точка имеет задержку поиска ~ 0,22-0,23 мс, конечная точка VPC с 2 (m4.large.elasticsearch) узлами данных имеет задержку поиска ~ 0,600-1,5 мс в зависимости отload.
Это приводит к замедлению всего веб-сайта, в то время как подключение к общедоступной конечной точке приводит к загрузке обычной страницы за 6-7 секунд, в то время как мы переходим на конечную точку VPC, загрузка страницы через 20-30 секунд, что также хорошокак система вниз.
Другая метрика, которую я наблюдал, была в Newrelic.Он группирует внешние показатели и их время отклика.Что касается общедоступной конечной точки, то, когда я перешел в VPC, это было примерно ~ 8,92 мс, это было приблизительно ~ 180-230 мс.
Кажется, это не составляет никакого труда, все, что нужно было сделать, - это перейти с публичной наКластер на основе VPC с узлами текущего поколения с лучшей готовностью и должен был обеспечить лучшую производительность, но результаты были иные.
Помимо предложенного ниже, попытался использовать следующую архитектуру
- 3 T2.Medium (data-node)
- 3 главных узла + 5 узлов данных.Независимо от используемых ресурсов у меня возникает одна и та же проблема с временем ответа.
Любые предложения по поводу такого поведения были бы хорошими.Дайте мне знать, если потребуется дополнительная информация.
Спасибо:)