Тесты производительности поиска ИИ Azure
Внимание
Эти тесты применяются к службам поиска, созданным до 3 апреля 2024 г. в развертываниях, работающих в более старой инфраструктуре. Тесты также применяются только к невекторным рабочим нагрузкам. Обновления ожидаются для служб и рабочих нагрузок в новых ограничениях.
Тесты производительности полезны для оценки потенциальной производительности в аналогичных конфигурациях. Фактическая производительность зависит от различных факторов, включая размер службы поиска и типы запросов, которые вы отправляете.
Чтобы оценить размер службы поиска, необходимой для рабочей нагрузки, мы выполнили несколько тестов, чтобы документировать производительность различных служб поиска и конфигураций.
Чтобы охватить разные типы вариантов использования, тесты выполнялись по двум основным сценариям:
- Поиск для электронной коммерции. Этот тест имитирует типичный сайт электронной коммерции и основывается на реальном примере скандинавской компании CDON.
- Поиск по документам. Этот сценарий состоит из поиска ключевых слов по крупным текстовым документам сайта Semantic Scholar. Он реализует типичное поведение при поиске по документам.
Эти тестовые сценарии достаточно хорошо отражают разные варианты использования, но в реальной среде каждый сценарий имеет свои особенности. Поэтому мы рекомендуем всегда выполнять тесты производительности по конкретным и реальным рабочим нагрузкам. Мы опубликовали для вас решение по тестированию производительности на основе JMeter, которое позволяет выполнить аналогичные тесты в вашей службе.
Методология тестирования
Чтобы проверить производительность поиска ИИ Azure, мы выполнили тесты для двух разных сценариев на разных уровнях и сочетаниях реплик и секций.
Для подготовки этих тестов использовалась следующая методология:
- Тест начинается со скорости
Xзапросов в секунду и продолжается в течение 180 секунд. Обычно выбиралось стартовое значение в 5 или 10 запросов в секунду. - Затем скорость увеличивается на
Xи тест продолжается еще 180 секунд. - Далее каждые 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.
Тест 1. Поиск для электронной коммерции
Этот текст был создан в сотрудничестве с компанией электронной коммерции CDON, крупнейшего в Скандинавии Интернет-магазина с представительствами в Швеции, Финляндии, Норвегии и Дании. На платформе CDON работают 1500 продавцов, предоставляющие более 8 млн товарных позиций в широком ассортименте категорий. В 2020 году услугами CDON воспользовались более 120 млн посетителей сайта и 2 млн активных покупателей. Дополнительные сведения об использовании службы "Поиск ИИ Azure" в CDON см. в этой статье.
Чтобы выполнить эти тесты, мы получили моментальный снимок поискового индекса рабочей базы CDON и несколько тысяч уникальных запросов от реальных посетителей веб-сайта.
Подробности сценария
- Число документов: 6 000 000.
- Размер индекса: 20 ГБ.
- Схема индекса: широкий индекс содержит в общей сложности 250 полей, из которых по 25 поддерживается поиск, а 200 используются для аспектов и фильтров.
- Типы запросов: полнотекстовые поисковые запросы, включающие аспекты, фильтры, сортировки и профили повышения.
Производительность S1
Число запросов в секунду
На следующей диаграмме показана самая высокая загрузка запросов, которые служба может обрабатывать в течение длительного периода времени с точки зрения запросов в секунду (QPS).
Задержка запросов
Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 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).
Задержка запросов
Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 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 даже при двух секциях.
Задержка запросов
Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 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 мс |
Тест 2. Поиск по документам
Подробности сценария
- Количество документов: 7,5 млн.
- Размер индекса: 22 ГБ.
- Схема индекса: 23 поля, 8 с возможностью поиска, 10 для фильтров и аспектов.
- Типы запросов: поиски по ключевым словам с аспектами и выделением совпадений.
Производительность S1
Число запросов в секунду
На следующей диаграмме показана самая высокая загрузка запросов, которые служба может обрабатывать в течение длительного периода времени с точки зрения запросов в секунду (QPS).
Задержка запросов
Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 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).
Задержка запросов
Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 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).
Задержка запросов
Задержка запросов зависит от нагрузки службы и служб в условиях повышенного стресса с более высокой средней задержкой запроса. В следующей таблице показаны 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 и ключевые факторы, влияющие на производительность.