Поделиться через


Тесты производительности поиска ИИ Azure

Внимание

Эти тесты применяются к службам поиска, созданным до 3 апреля 2024 г. в развертываниях, работающих в более старой инфраструктуре. Тесты также применяются только к невекторным рабочим нагрузкам. Обновления ожидаются для служб и рабочих нагрузок в новых ограничениях.

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

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

Чтобы охватить разные типы вариантов использования, тесты выполнялись по двум основным сценариям:

  • Поиск для электронной коммерции. Этот тест имитирует типичный сайт электронной коммерции и основывается на реальном примере скандинавской компании CDON.
  • Поиск по документам. Этот сценарий состоит из поиска ключевых слов по крупным текстовым документам сайта Semantic Scholar. Он реализует типичное поведение при поиске по документам.

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

Методология тестирования

Чтобы проверить производительность поиска ИИ Azure, мы выполнили тесты для двух разных сценариев на разных уровнях и сочетаниях реплик и секций.

Для подготовки этих тестов использовалась следующая методология:

  1. Тест начинается со скорости X запросов в секунду и продолжается в течение 180 секунд. Обычно выбиралось стартовое значение в 5 или 10 запросов в секунду.
  2. Затем скорость увеличивается на X и тест продолжается еще 180 секунд.
  3. Далее каждые 180 секунд скорость запросов увеличивается на X, пока среднее время задержки не превысит значение 1000 мс или процент успешного выполнения запросов не упадет ниже 99 %.

На следующем графике представлен визуальный пример того, как выглядит загрузка запроса теста:

Пример теста

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

Внимание

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

Определения

  • Максимальное число QPS — максимальное число QPS основано на максимальном уровне QPS, достигнутом в тесте, где 99% запросов успешно завершены без регулирования и средней задержки осталось до 1000 мс.

  • Доля от максимального QPS — процентная доля от максимального количества запросов в секунду (QPS), достигнутого в конкретном тесте. Например, если некоторый тест показал QPS = 100, то 20 % от этого значения составляет 20 запросов в секунду.

  • Задержка — задержка сервера для запроса; эти числа не включают задержку кругового пути (RTT). Значения находятся в миллисекундах (мс).

Отказ от тестирования

Код, используемый для выполнения этих тестов, доступен в репозитории azure-search-performance-testing . Стоит отметить, что мы наблюдали немного более низкие уровни QPS с решением тестирования производительности JMeter, чем в тестах. Такая разница объясняется различиями в методиках тестирования. Это еще раз напоминает нам о необходимости использовать тесты производительности в среде, максимально приближенной к реальной среде рабочей нагрузки.

Внимание

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

Если у вас возникли вопросы или проблемы, обратитесь к нам по адресу azuresearch_contact@microsoft.com.

Логотип CDON

Этот текст был создан в сотрудничестве с компанией электронной коммерции CDON, крупнейшего в Скандинавии Интернет-магазина с представительствами в Швеции, Финляндии, Норвегии и Дании. На платформе CDON работают 1500 продавцов, предоставляющие более 8 млн товарных позиций в широком ассортименте категорий. В 2020 году услугами CDON воспользовались более 120 млн посетителей сайта и 2 млн активных покупателей. Дополнительные сведения об использовании службы "Поиск ИИ Azure" в CDON см. в этой статье.

Чтобы выполнить эти тесты, мы получили моментальный снимок поискового индекса рабочей базы CDON и несколько тысяч уникальных запросов от реальных посетителей веб-сайта.

Подробности сценария

  • Число документов: 6 000 000.
  • Размер индекса: 20 ГБ.
  • Схема индекса: широкий индекс содержит в общей сложности 250 полей, из которых по 25 поддерживается поиск, а 200 используются для аспектов и фильтров.
  • Типы запросов: полнотекстовые поисковые запросы, включающие аспекты, фильтры, сортировки и профили повышения.

Производительность S1

Число запросов в секунду

На следующей диаграмме показана самая высокая загрузка запросов, которые служба может обрабатывать в течение длительного периода времени с точки зрения запросов в секунду (QPS).

Наивысший стабильный уровень QPS в примере для электронной коммерции S1

Задержка запросов

Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 25-й, 50-й, 75-й, 90-й, 95-й и 99-й процентиль задержки запросов для трех различных уровней использования.

Доля от максимального QPS Средняя задержка 25% 75% 90 % 95 % 99 %
20% 104 мс 35 мс 115 мс 177 мс 257 мс 738 мс
50% 140 мс 47 мс 144 мс 241 мс 400 мс 1175 мс
80% 239 мс 77 мс 248 мс 466 мс 763 мс 1752 мс

Производительность S2

Число запросов в секунду

На следующей диаграмме показана самая высокая загрузка запросов, которые служба может обрабатывать в течение длительного периода времени с точки зрения запросов в секунду (QPS).

Наивысший стабильный уровень QPS в примере для электронной коммерции S2

Задержка запросов

Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 25-й, 50-й, 75-й, 90-й, 95-й и 99-й процентиль задержки запросов для трех различных уровней использования.

Доля от максимального QPS Средняя задержка 25% 75% 90 % 95 % 99 %
20% 56 мс 21 мс 68 мс 106 мс 132 мс 210 мс
50% 71 мс 26 мс 83 мс 132 мс 177 мс 329 мс
80% 140 мс 47 мс 153 мс 293 мс 452 мс 924 мс

Производительность S3

Число запросов в секунду

На следующей диаграмме показана самая высокая загрузка запросов, которые служба может обрабатывать в течение длительного периода времени с точки зрения запросов в секунду (QPS).

Наивысший стабильный уровень QPS в примере для электронной коммерции S3

В этом примере мы видим, что добавление второй секции существенно повышает значение максимального QPS, но эффект от третьей секции пренебрежимо мал. Такое низкое улучшение предположительно связано с тем, что все данные уже полностью загружаются в активную память S3 даже при двух секциях.

Задержка запросов

Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 25-й, 50-й, 75-й, 90-й, 95-й и 99-й процентиль задержки запросов для трех различных уровней использования.

Доля от максимального QPS Средняя задержка 25% 75% 90 % 95 % 99 %
20% 50 мс 20 мс 64 мс 83 мс 98 мс 160 мс
50% 62 мс 24 мс 80 мс 107 мс 130 мс 253 мс
80% 115 мс 38 мс 121 мс 218 мс 352 мс 828 мс

Подробности сценария

  • Количество документов: 7,5 млн.
  • Размер индекса: 22 ГБ.
  • Схема индекса: 23 поля, 8 с возможностью поиска, 10 для фильтров и аспектов.
  • Типы запросов: поиски по ключевым словам с аспектами и выделением совпадений.

Производительность S1

Число запросов в секунду

На следующей диаграмме показана самая высокая загрузка запросов, которые служба может обрабатывать в течение длительного периода времени с точки зрения запросов в секунду (QPS).

Наивысший стабильный уровень QPS в примере поиска по документам S1

Задержка запросов

Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 25-й, 50-й, 75-й, 90-й, 95-й и 99-й процентиль задержки запросов для трех различных уровней использования.

Доля от максимального QPS Средняя задержка 25% 75% 90 % 95 % 99 %
20% 67 мс 44 мс 77 мс 103 мс 126 мс 216 мс
50% 93 мс 59 мс 110 мс 150 мс 184 мс 304 мс
80% 150 мс 96 мс 184 мс 248 мс 297 мс 424 мс

Производительность S2

Число запросов в секунду

На следующей диаграмме показана самая высокая загрузка запросов, которые служба может обрабатывать в течение длительного периода времени с точки зрения запросов в секунду (QPS).

Наивысший стабильный уровень QPS в примере поиска по документам S2

Задержка запросов

Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 25-й, 50-й, 75-й, 90-й, 95-й и 99-й процентиль задержки запросов для трех различных уровней использования.

Доля от максимального QPS Средняя задержка 25% 75% 90 % 95 % 99 %
20% 45 мс 31 мс 55 мс 73 мс 84 мс 109 мс
50% 63 мс 39 мс 81 мс 106 мс 123 мс 163 мс
80% 115 мс 73 мс 145 мс 191 ms 224 мс 291 мс

Производительность S3

Число запросов в секунду

На следующей диаграмме показана самая высокая загрузка запросов, которые служба может обрабатывать в течение длительного периода времени с точки зрения запросов в секунду (QPS).

Наивысший стабильный уровень QPS в примере поиска по документам S3

Задержка запросов

Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 25-й, 50-й, 75-й, 90-й, 95-й и 99-й процентиль задержки запросов для трех различных уровней использования.

Доля от максимального QPS Средняя задержка 25% 75% 90 % 95 % 99 %
20% 43 мс 29 мс 53 мс 74 мс 86 мс 111 мс
50% 65 мс 37 мс 85 мс 111 мс 128 мс 164 мс
80% 126 мс 83 мс 162 мс 205 мс 233 мс 281 мс

Общие выводы

С помощью этих тестов вы можете получить представление о производительности предложений поиска ИИ Azure. Также вы можете наблюдать разницу между производительностью служб на разных уровнях.

Вот несколько важных выводов, которые можно сделать по результатам тестов:

  • Уровень S2 обычно выдерживает объем запросов по меньшей мере вчетверо больше, чем уровень S1.
  • Как правило, S2 имеет меньшую задержку, чем S1 при сопоставимых томах запросов
  • По мере добавления реплик допустимое значение QPS для поиска увеличивается почти линейно (то есть если одна реплика обрабатывает около 10 запросов в секунду, то пять реплик смогут выдержать примерно 50 запросов в секунду).
  • Чем выше нагрузка на службу, тем выше средняя задержка

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

Следующие шаги

Теперь, когда вы видели тесты производительности, вы можете узнать больше о том, как анализировать производительность поиска ИИ Azure и ключевые факторы, влияющие на производительность.