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

В этой статье описываются инструменты, поведение и подходы для анализа производительности запросов и индексирования в службе "Поиск ИИ Azure".

Эта статья относится только к классическим сценариям поиска полнотекстового поиска.

Определение базовых показателей

В любой крупной реализации важно провести тестирование производительности вашей службы Поиск с использованием ИИ Azure, прежде чем вводить ее в эксплуатацию. Вы должны протестировать ожидаемую нагрузку поискового запроса, но и ожидаемые рабочие нагрузки приема данных (если это возможно, одновременное выполнение обеих рабочих нагрузок). Эталонные показатели помогают выбрать правильный уровень службы поиска, конфигурацию службы и оценить ожидаемую задержку запросов.

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

Использование ведения журнала ресурсов

Самым важным средством диагностики в распоряжении администратора является ведение журнала ресурсов. Ведение журнала ресурсов — это сбор операционных данных и метрик службы поиска. Ведение журнала ресурсов включено с помощью Azure Monitor. За использование Azure Monitor и хранение данных взимается определенная плата, но эта служба может сыграть важную роль при диагностике проблем с производительностью.

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

Ведение журнала ресурсов предоставляет варианты хранения записываемой информации. Мы рекомендуем использовать Log Analytics, чтобы выполнять расширенные запросы Kusto к данным для поиска ответов на различные вопросы об использовании и производительности.

На страницах портала службы поиска можно включить ведение журнала с помощью параметров диагностики, а затем настроить запросы Kusto к Log Analytics в разделе Журналы. Сведения о том, как отправлять журналы ресурсов в рабочую область Log Analytics, где их можно анализировать с помощью запросов журналов, см. в статье Сбор и анализ журналов ресурсов из ресурса Azure.

Поведение ограничения

Ограничение возникает, когда служба поиска исчерпала свои возможности. Регулирование может происходить во время запросов или индексирования. Со стороны клиента вызов API при регулировании приводит к возникновению HTTP-ответа 503. Во время индексирования также существует возможность получения HTTP-ответа 207, указывающего, что один или несколько элементов не удалось индексировать. Эта ошибка является индикатором того, что служба поиска почти исчерпала свою емкость.

Как правило, постарайтесь количественно оценить степень ограничения и выявить любые закономерности. Например, если один поисковый запрос из 500 000 затормаживается, это может не стоить дальнейшего исследования. Однако если в течение некоторого времени ограничивается значительная доля запросов, это более серьезный повод для беспокойства. Оценка ограничения в течение определенного периода также помогает определить временные рамки, когда ограничение более вероятно, и решить, как лучше учесть это в своем планировании.

Простым решением для большинства проблем с ограничением является увеличение ресурсов для службы поиска (обычно это реплики для ограничения запросов или разделы для ограничения индексирования). Однако увеличение реплик или разделов добавляет затраты, поэтому важно знать причину, почему происходит ограничение скорости вовсе. Анализ условий, вызывающих регулирование, рассматривается в следующих нескольких разделах.

Ниже приведен пример запроса Kusto, который получает разбивку HTTP-ответов от службы поиска, работающей под нагрузкой. В течение 7-дневного периода отрисованная линейчатая диаграмма показывает, что относительно большой процент поисковых запросов был регулироваться по сравнению с числом успешных ответов (200).

AzureDiagnostics
| where TimeGenerated > ago(7d)
| summarize count() by resultSignature_d 
| render barchart 

Анализ регулирования за определенный период может помочь определить моменты, когда регулирование происходит чаще всего. В приведённом ниже примере на графике временных рядов показано количество ограниченных запросов за указанный промежуток времени. В этом случае ограниченные запросы коррелировали с временными промежутками, когда проводились тесты производительности.

let ['_startTime']=datetime('2024-02-25T20:45:07Z');
let ['_endTime']=datetime('2024-03-03T20:45:07Z');
let intervalsize = 1m; 
AzureDiagnostics 
| where TimeGenerated > ago(7d)
| where resultSignature_d != 403 and resultSignature_d != 404 and OperationName in ("Query.Search", "Query.Suggest", "Query.Lookup", "Query.Autocomplete")
| summarize 
  ThrottledQueriesPerMinute=bin(countif(OperationName in ("Query.Search", "Query.Suggest", "Query.Lookup", "Query.Autocomplete") and resultSignature_d == 503)/(intervalsize/1m), 0.01)
  by bin(TimeGenerated, intervalsize)
| render timechart   

Измерение отдельных запросов

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

В примере ниже был выполнен поисковый запрос REST в службе поиска. Поиск по искусственному интеллекту Azure включает в каждый ответ количество миллисекунд, которое требуется для выполнения запроса, что отображается на вкладке "Заголовки" в "времени выполнения". Рядом с "Статус" в верхней части ответа вы найдете длительность кругового пути, в этом случае 125 миллисекунд (мс). В разделе результатов выбрана вкладка "Заголовки". Используя эти два значения, выделенные красным полем на изображении ниже, мы видим, что служба поиска заняла 21 мс, чтобы завершить поисковый запрос, и весь запрос на круговую поездку клиента занял 125 мс. Вычитая эти два числа, мы можем определить, что потребовалось 104-мс дополнительного времени для передачи поискового запроса в службу поиска и передачи результатов поиска клиенту.

Этот метод помогает изолировать задержку сети от других факторов, влияющих на производительность запросов.

Скорость запросов

Одной из возможных причин, по которой служба поиска начинает регулировать запросы, является исключительно большое количество запросов, где объем фиксируется как число запросов в секунду (QPS) или запросов в минуту (QPM). По мере того как служба поиска получает больше QPS, обычно требуется все больше времени для ответа на эти запросы, пока она не перестает справляться, после чего начинает отправлять обратно HTTP-ответ 503 (ограничение).

В следующем запросе Kusto показан объем запросов (в QPM), а также средняя длительность запроса в миллисекундах (AvgDurationMS) и среднее количество документов (AvgDocCountReturned), возвращаемых в каждом запросе.

AzureDiagnostics
| where OperationName == "Query.Search" and TimeGenerated > ago(1d)
| extend MinuteOfDay = substring(TimeGenerated, 0, 16) 
| project MinuteOfDay, DurationMs, Documents_d, IndexName_s
| summarize QPM=count(), AvgDuractionMs=avg(DurationMs), AvgDocCountReturned=avg(Documents_d)  by MinuteOfDay
| order by MinuteOfDay desc 
| render timechart

Влияние индексирования на запросы

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

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

В этом разделе содержится набор запросов, которые помогают визуализировать скорости поиска и индексирования. В этих примерах диапазон времени задается в запросе. При выполнении запросов в портале Azure не забудьте указать параметр В запросе.

Средняя задержка запросов

В запросе ниже для отображения средней задержки поисковых запросов используется интервал в 1 минуту. На диаграмме видно, что средняя задержка была низкой до 5:45 вечера и длилась до 5:53 вечера.

let intervalsize = 1m; 
let _startTime = datetime('2024-02-23 17:40');
let _endTime = datetime('2024-02-23 18:00');
AzureDiagnostics
| where TimeGenerated between(['_startTime']..['_endTime']) // Time range filtering
| summarize AverageQueryLatency = avgif(DurationMs, OperationName in ("Query.Search", "Query.Suggest", "Query.Lookup", "Query.Autocomplete"))
    by bin(TimeGenerated, intervalsize)
| render timechart

Среднее число запросов в минуту (QPM)

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

let intervalsize = 1m; 
let _startTime = datetime('2024-02-23 17:40');
let _endTime = datetime('2024-02-23 18:00');
AzureDiagnostics
| where TimeGenerated between(['_startTime'] .. ['_endTime']) // Time range filtering
| summarize QueriesPerMinute=bin(countif(OperationName in ("Query.Search", "Query.Suggest", "Query.Lookup", "Query.Autocomplete"))/(intervalsize/1m), 0.01)
  by bin(TimeGenerated, intervalsize)
| render timechart

Операции индексирования в минуту (OPM)

Здесь мы рассмотрим количество операций индексирования в минуту. На диаграмме видно, что большой объем данных был индексирован в 5:42 вечера и закончился в 5:50 вечера. Индексирование началось за 3 минуты до увеличения задержки поисковых запросов и завершилось за 3 минуты до того, как задержка исчезла.

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

let intervalsize = 1m; 
let _startTime = datetime('2024-02-23 17:40');
let _endTime = datetime('2024-02-23 18:00');
AzureDiagnostics
| where TimeGenerated between(['_startTime'] .. ['_endTime']) // Time range filtering
| summarize IndexingOperationsPerSecond=bin(countif(OperationName == "Indexing.Index")/ (intervalsize/1m), 0.01)
  by bin(TimeGenerated, intervalsize)
| render timechart 

Обработка фоновых служб

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

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

Дальнейшие шаги

Ознакомьтесь с этими статьями, связанными с анализом производительности службы.

• Советы по улучшению производительности
• Выбор уровня службы
• Управление емкостью
• Пример использования когнитивного поиска для поддержки сложных сценариев ИИ