Устранение неполадок, связанных с низкой производительностью Поиска Azure

Я наблюдаю неустойчивую производительность экземпляра Azure Search Basic. В нашем индексе всего 1544 документа и размер 28 МБ, поэтому я ожидаю, что поиск будет очень быстрым.

Azure Application Insights сообщает о 4,7 тыс. Вызовов службы поиска Azure из нашего приложения за последние 12 часов, при среднем времени ответа 2,1 с и стандартном отклонении 35,8 с (!).

Я лично наблюдаю нестабильную производительность во время ручного тестирования. Запрос может занять более 20 секунд в один момент, а чуть позже тот же запрос займет менее 100 мс.

Там запросы очень простые. Вот пример строки запроса:

api-version = 28.02.2015 & api-key = удалено & search = &% 24count = true &% 24top = 10 &% 24skip = 0 & searchMode = all & scoringProfile = FieldBoost &% 24orderby = sortableTitle

Что я могу сделать для дальнейшего устранения этой проблемы?


azure azure-cognitive-search
person Kevin Krueger    schedule 02.05.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Во-первых, я предполагаю, что у вас довольно равномерное распределение запросов, что означает, что в зависимости от ваших чисел вы выполняете всего ~ 1 запрос в секунду. Это звучит правильно? Если нет, и вы видите большие всплески запросов, вполне возможно, что у вас недостаточно реплик (копий индекса) для обработки нагрузки запроса. Обратите внимание, что базовая услуга с одной репликой предназначена для обработки небольших однозначных запросов в секунду (хотя это может сильно варьироваться в зависимости от сложности или простоты запросов). Если вы выйдете за пределы услуги, задержка, безусловно, может стать проблемой. Хороший способ вникнуть в это - использовать Поиск в Azure. Аналитика трафика, которая может отображать показатели поиска, которые включают такие данные, как количество запросов в секунду за различные периоды времени, а также показатели задержки, которые мы наблюдаем внутри компании.

Кроме того, что наиболее важно, постарайтесь как можно больше повторно использовать HTTP-соединения и, если возможно, использовать пул HTTP-соединений. Кстати, в .NET вам следует повторно использовать один экземпляр HttpClient или экземпляр SearchIndexClient, если вы используете наш пакет SDK для поиска Azure.

person Liam Cavanagh - MSFT    schedule 03.05.2016
comment
Наш трафик действительно различается, поэтому он более концентрированный. В пиковое время с 7 утра до 8 утра было 2270 звонков, что все еще меньше 1 QPS. Запросы поступают непосредственно из браузеров наших пользователей, поэтому нет возможности объединять соединения. Возможно ли, что уровень Free обеспечит лучшую производительность, чем базовый? Я включил аналитику, чтобы собирать больше данных. - person Kevin Krueger; 03.05.2016
comment
Да, возможно, что время от времени вы увидите лучшую производительность с бесплатным, но вы также должны иметь в виду, что бесплатная - это многопользовательская система, а это означает, что использование другими пользователями, использующими бесплатную версию, может повлиять на общую производительность службы. Базовый и Стандартный - это выделенные ресурсы, что означает, что вы должны видеть стабильный уровень производительности. Фактически, если вы посмотрите на данные из аналитики поискового трафика и увидите непостоянную производительность для постоянного уровня трафика, мы бы хотели изучить это намного глубже. - person Liam Cavanagh - MSFT; 03.05.2016
comment
На данный момент это похоже на временную проблему в понедельник утром. Я оставлю аналитику в будущем и сообщу, если я смогу собрать какие-то действенные данные. - person Kevin Krueger; 05.05.2016

arrow_upward
0
arrow_downward

Я собрал больше данных и опубликовал мои результаты на форуме Поиска Azure.

Замедление связано с тем, что мы запускаем один базовый экземпляр, а развертывание кода командой поиска Azure вызывает кратковременное (несколько минут по моему опыту) прерывание / ухудшение обслуживания.

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

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

person Kevin Krueger    schedule 13.05.2016