Как устранить удушение API службы поиска Azure

Question

Нашей целью является полное устранение удушения службы поиска Azure.Первоначально мы начали с 3 реплик и 1 раздела на уровне S1.Мы получали много удушения, иногда даже до 1,5% запросов удушалось.Мы предприняли некоторые меры для решения этой проблемы:

1) - Мы начали нагрузочное тестирование службы и разработали базовое требование / сек для 3 реплик.Каждый раз, когда мы достигаем ~ 37 req / sec, наш сервис будет замедляться.

2) - Мы не хотели, чтобы наши пользователи видели ошибки, и чтобы облегчить проблему, мы реализовали политику кратковременного временного отказа, которая повторяет вызовкогда API поиска Azure возвращает ответ 5xx или 408 (время ожидания запроса).Это хорошо сработало для нас.

3) Проблема все еще осталась;мы все еще дросселируем при 37 рек / сек, что нам кажется очень низким.Это означает, что мы примерно получаем МАКС ~12 req/sec за реплику.Таким образом, мы настроили производительность наших запросов (удалили фасеты, поле высокой мощности из нашего индекса, очистили свойства нашего поля и удостоверились, что индекс выполняет абсолютный минимум), наши запросы стали немного быстрее и не сильно повлияли на фронт регулирования.

4) Поэтому мы решили перейти к ПЯТИ репликам, чтобы избавиться от удушения.Мы снова провели нагрузочное тестирование, и теперь служба может обрабатывать ~ 59 требований / сек.Это снова становится ~12 requests/sec на реплику

~12 requests/sec на реплику похоже на НИЗКУЮ емкость для сервера стандартного уровня.Это огромная проблема для нас, так как наш трафик будет только увеличиваться (не говоря уже о том, чтобы иметь дело с неприятным трафиком ботов)

Эти тестовые показатели выглядят прямо для поисковой команды Azure?

Или мы что-то не так делаем?Я могу предоставить поисковый запрос при необходимости.

Любая помощь будет высоко ценится!

Спасибо!

Answer 1

Спасибо за подробный ответ Мэтью!

1) Мы следовали упомянутым здесь стратегиям: Стратегии развертывания и рекомендации по оптимизации производительности при поиске в Azure

2) Мы думали о том, чтобы запустить индексатор в выключенном состоянии.- пиковые часы, но наш вариант использования требует от нас более частого запуска нашего индекса (установленного для запуска каждые 15 минут)

3) Да, наш запрос может быть немного сложным.

Размер индекса:160 тысяч строк;Количество полей: 108

Вот пример запроса с нашей целевой страницы:

    "$count=false&facet=IsUsed,count:500&facet=Year,count:500&facet=ChassisMake,count:500&facet=ChassisModel,count:500&facet=NormalTrim,count:500&facet=CabType,count:500&facet=RoofHeight,count:500&facet=ChassisType,count:500&facet=DriveTrain,count:500&facet=RearWheels,count:500&facet=FuelType,count:500&facet=NormalEngine,count:500&facet=NormalTransmission,count:500&facet=NormalColor,count:500&facet=GVWR,count:500&facet=Wheelbase,count:500&facet=CA,count:500&facet=BodyType,count:500&facet=BodyMake,count:500&facet=HasSnowPlow,count:500&facet=HasCrane,count:500&facet=HasVanPartition,count:500&facet=BodyLength,count:500&facet=DealerNumericID,count:2000&$filter=((search.in(CMID, '5e3c3789-bb0f-4e6a-8c8b-a0fc31568d85') ) and ( HasLiftKit eq null )) and (IsDealerLive eq true) and  IsDemoDealer eq false  and  DepartureDate eq null and  IsUsed eq false  and geo.distance(GeoPoint, geography'POINT(-121.141636 38.666597)') le 80&queryType=simple&scoringParameter=IsUpfit-'true'&scoringParameter=GeoPoint-'-121.141636','38.666597'&scoringProfile=locator-distance&searchMode=any&$select=ID,DealerID,IsUsed,Featured,CustomTitle,StockNumber,CleanStockNumber,Vin,ChassisImagePathTemplate,ChassisBlobLastUpdated,BodyImagePathTemplate,BodyBlobLastUpdated,ChassisModelVINDecodingID,ChassisManufacturerID,BodyManufacturerID,BodyType_Code,ChassisMake,ChassisModel,DealerNumericID,Year,BodyTypeID,BodyType,EnabledAttributes,Mileage,CabType,DriveTrain,RearAxle,FuelType,Transmission,Color,RoofHeight,SalePrice,OnSale,SaleStartDate,SaleEndDate,SaleShowSaleBanner&$skip=0&$top=10
SearchString:*"

Этот запрос выполняется за 75 мс, когда индекс нагревается, и за ~ 300 мс, когда индексне разогревается.

Пожалуйста, дайте нам, что вы думаете.

Спасибо большое!

Answer 2

Масштаб в Azure Search - сложная тема.Я рекомендую следующее:

1. Обзор Стратегии развертывания и рекомендации по оптимизации производительности при поиске Azure

2. С Разработка базовых номеров :

   Поиск Azure не выполняет задачи индексирования в фоновом режиме.Если ваша служба обрабатывает запросы и индексирует рабочие нагрузки одновременно, учтите это, введя задания индексации в свои тесты запросов или изучив варианты запуска заданий индексирования в нерабочее время.

   Если вы работаетеОдновременное индексирование заданий во время выполнения запросов, попробуйте запустить их в часы пик или еще больше увеличить масштаб

3. Вы упоминаете, что чувствуете, что частота запросов слишком низкая - 12 запросов в секунду.Похоже, что вы уже предприняли некоторые шаги, перечисленные на странице оптимизации производительности, включая удаление полей с большим количеством элементов из вашего индекса.Я подозреваю, что у вас медленные отдельные запросы. Не могли бы вы увеличить количество имеющихся у вас разделов?

С Масштабирование для медленных отдельных запросов :

Раздел - это механизм разделения ваших данных на дополнительные ресурсы.Добавление второго раздела делит данные на два, третий раздел делит их на три и так далее.Одним положительным побочным эффектом является то, что медленные запросы иногда выполняются быстрее из-за параллельных вычислений.Мы отметили распараллеливание запросов с низкой избирательностью, таких как запросы, которые соответствуют многим документам, или фасетов, обеспечивающих подсчет большого количества документов.Поскольку для оценки релевантности документов или подсчета количества документов требуются значительные вычисления, добавление дополнительных разделов помогает быстрее выполнять запросы.

Мы можем предоставить более подробные рекомендации, если вы поделитесь своим запросом,как может выглядеть пример записи и сколько записей в вашем индексе.