Analýza výkonu ve službě Azure AI Vyhledávač

Tento článek popisuje nástroje, chování a přístupy k analýze výkonu dotazů a indexování ve službě Azure AI Vyhledávač.

Tento článek se týká pouze klasických scénářů fulltextového vyhledávání.

Rozvíjet základní čísla

V jakékoli rozsáhlé implementaci je důležité provést výkonnostní srovnávací test služby Azure AI Vyhledávač před jejím nasazením do produkčního prostředí. Měli byste otestovat zatížení vyhledávacího dotazu, které očekáváte, ale také očekávané úlohy příjmu dat (pokud je to možné, spustit obě úlohy současně). Srovnávací testy pomáhají ověřit správnou úroveň vyhledávání, konfiguraci služby a očekávanou latenci dotazů.

Pokud chcete izolovat účinky architektury distribuované služby, zkuste otestovat konfigurace služeb jedné repliky a jednoho oddílu.

Note

U úrovní optimalizovaných pro úložiště (L1 a L2) byste měli očekávat nižší propustnost dotazů a vyšší latenci než úrovně Standard.

Použijte protokolování prostředků

Nejdůležitějším diagnostickým nástrojem, který má správce k dispozici, je protokolování prostředků. Sběr údajů o prostředcích je shromažďování provozních dat a metrik o vaší vyhledávací službě. Protokolování prostředků je povolené prostřednictvím služby Azure Monitor. S používáním služby Azure Monitor a ukládáním dat jsou spojené náklady, ale pokud jej povolíte pro svoji službu, může být instrumentálním pomocníkem při řešení problémů s výkonem.

Následující obrázek znázorňuje řetěz událostí v požadavku dotazu a odpovědi. Latence může nastat v libovolné z nich, ať už během přenosu sítě, zpracování obsahu ve vrstvě aplikačních služeb nebo ve vyhledávací službě. Klíčovou výhodou protokolování prostředků je to, že aktivity se protokolují z pohledu vyhledávací služby, což znamená, že vám protokol může pomoct určit, jestli je problém s výkonem způsobený problémy s dotazem nebo indexováním nebo jiným bodem selhání.

Řetěz protokolovaných událostí

Zaznamenávání prostředků poskytuje možnosti pro ukládání zaznamenaných informací. Doporučujeme používat Log Analytics , abyste mohli spouštět pokročilé dotazy Kusto na data, abyste mohli zodpovědět mnoho otázek týkajících se využití a výkonu.

Na stránkách portálu vyhledávací služby můžete povolit protokolování prostřednictvím nastavení diagnostiky a pak vydat dotazy Kusto na Log Analytics tak, že zvolíte Protokoly. Informace o tom, jak odeslat protokoly prostředků do pracovního prostoru Log Analytics, kde je můžete analyzovat pomocí dotazů protokolu, najdete v tématu Shromažďování a analýza protokolů prostředků z prostředku Azure.

Chování omezení

Dochází k omezení, když je vyhledávací služba na maximu své kapacity. Omezování může nastat během dotazů nebo indexování. Na straně klienta má volání rozhraní API za následek odpověď HTTP 503, když došlo k omezení rychlosti. Během indexování existuje také možnost přijetí odpovědi HTTP 207, která indikuje, že se jedné nebo více položek nepodařilo indexovat. Tato chyba je indikátorem, že vyhledávací služba se blíží kapacitě.

Obecná zásada je pokusit se kvantifikovat úroveň omezování a jakékoliv vzorce. Pokud například dojde k omezení jednoho vyhledávacího dotazu z 500 000, nemusí to stát za to vyšetřovat. Pokud je však v určitém období omezeno velké procento dotazů, bude to větší problém. Když sledujete omezování během určitého období, pomůže vám to také určit časové rámce, ve kterých je pravděpodobné, že k omezování dojde, a umožní vám se rozhodnout, jak se tomu nejlépe přizpůsobit.

Jednoduchou opravou většiny problémů s omezováním je vyvolání dalších prostředků ve vyhledávací službě (obvykle repliky pro omezování založené na dotazech nebo oddíly pro omezování na základě indexování). Zvýšení počtu replik nebo oddílů ale zvyšuje náklady, a proto je důležité pochopit, proč vůbec dochází k omezení výkonu. Zkoumání podmínek, které vedou ke škrcení, bude vysvětleno v následujících několika částech.

Níže je příklad dotazu Kusto, který dokáže identifikovat rozpis odpovědí HTTP z vyhledávací služby, která byla zatížena. Vykreslovaný pruhový graf během 7denního období ukazuje, že v porovnání s počtem úspěšných (200) odpovědí došlo k omezení relativně velkého procenta vyhledávacích dotazů.

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

Pruhový graf počtu chyb HTTP

Zkoumání škrcení v určitém časovém období vám může pomoct určit chvíle, kdy ke škrcení dochází častěji. V následujícím příkladu se graf časových řad používá k zobrazení počtu omezených dotazů, ke kterým došlo v zadaném časovém rámci. V tomto případě škrcené dotazy korelují s časy, kdy byl proveden srovnávací test výkonu.

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

Spojnicový graf omezených dotazů

Měření jednotlivých dotazů

V některých případech může být užitečné otestovat jednotlivé dotazy a zjistit, jak fungují. K tomu je důležité zjistit, jak dlouho trvá vyhledávací službě dokončit svou práci, stejně jako jak dlouho trvá vyřízení obousměrné žádosti od klienta a zpět ke klientovi. Diagnostické protokoly je možné použít k vyhledání jednotlivých operací, ale může být jednodušší to udělat z klienta REST.

V následujícím příkladu se spustil vyhledávací dotaz založený na REST. Azure AI Vyhledávač zahrnuje do každé odpovědi počet milisekund potřebných k dokončení dotazu, který je viditelný na kartě Záhlaví v "uplynulé době". Vedle položky Stav v horní části odpovědi najdete délku zpáteční cesty, v tomto případě 125 milisekund (ms). V oddílu výsledků byla vybrána karta Záhlaví. Pomocí těchto dvou hodnot, zvýrazněných červeným polem na obrázku níže, vidíme, že vyhledání dotazu trvalo službě 21 ms a celá zpáteční žádost klienta trvala 125 ms. Odečtením těchto dvou čísel můžeme zjistit, že přenos vyhledávacího dotazu do vyhledávací služby a přenos výsledků hledání zpět klientovi trvalo 104 ms.

Tato technika pomáhá izolovat latence sítě od jiných faktorů ovlivňujících výkon dotazů.

Metriky doby trvání dotazu

Sazby dotazů

Jedním z možných důvodů, proč vaše vyhledávací služba škrtí požadavky, může být obrovský objem dotazů prováděných, kdy se tento objem zaznamenává jako dotazy za sekundu (QPS) nebo dotazy za minutu (QPM). Jakmile vaše vyhledávací služba přijímá více QPS, bude typicky trvat déle reagovat na tyto dotazy, až nakonec nebude stíhat a začne odesílat zpět 503 odpověď HTTP s omezením.

Následující dotaz Kusto zobrazuje objem dotazu měřený v QPM spolu s průměrnou dobou trvání dotazu v milisekundách (AvgDurationMS) a průměrným počtem dokumentů (AvgDocCountReturned) vrácených v každém z nich.

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

Graf zobrazující dotazy za minutu

Tip

Pokud chcete zobrazit data za tímto grafem, odeberte čáru | render timechart a pak znovu spusťte dotaz.

Dopad indexování na dotazy

Důležitým faktorem, který je potřeba vzít v úvahu při pohledu na výkon, je, že indexování používá stejné prostředky jako vyhledávací dotazy. Pokud indexujete velké množství obsahu, můžete očekávat, že se zvýší latence, protože se služba snaží pojmout obě úlohy.

Pokud se dotazy zpomalují, podívejte se na načasování aktivity indexování a zjistěte, jestli se shoduje se snížením výkonu dotazů. Například indexer spouští denní nebo hodinovou úlohu, která koreluje s nižším výkonem vyhledávacích dotazů.

Tato část obsahuje sadu dotazů, které vám pomůžou vizualizovat sazby hledání a indexování. V těchto příkladech je časový rozsah nastavený v dotazu. Při spouštění dotazů v Azure portálu nezapomeňte označit Nastavit v dotazu.

Nastavení časových rozsahů v nástroji pro dotazy

Průměrná latence dotazů

V následujícím dotazu se k zobrazení průměrné latence vyhledávacích dotazů používá velikost intervalu 1 minuta. Z grafu vidíme, že průměrná latence byla nízká do 5:45 a trvala do 5:53.00.

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

Graf zobrazující průměrnou latenci dotazů

Průměrné dotazy za minutu (QPM)

Následující dotaz se podívá na průměrný počet dotazů za minutu, aby se zajistilo, že v požadavcích hledání nedošlo ke špičkám, které by mohly ovlivnit latenci. Z grafu vidíme, že je nějaká odchylka, ale nic neznamená špičku v počtu požadavků.

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

Graf zobrazující průměrné dotazy za minutu

Operace indexování za minutu (OPM)

Tady se podíváme na počet operací indexování za minutu. Z grafu vidíme, že velké množství dat bylo indexováno v 17:42 a skončilo v 17:50. Toto indexování začalo 3 minuty předtím, než se vyhledávací dotazy začaly zpožďovat, a skončilo 3 minuty předtím, než vyhledávací dotazy přestaly být latentní.

Z tohoto přehledu vidíme, že přibližně 3 minuty trvalo, než vyhledávací služba přestane být zaneprázdněná, aby indexování ovlivnilo latenci dotazů. Vidíme také, že po dokončení indexování trvalo další 3 minuty, než vyhledávací služba dokončila veškerou práci z nově indexovaného obsahu a aby se vyřešila latence dotazů.

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

Graf znázorňující operace indexování za minutu

Zpracování služby na pozadí

Občasné špičky v latenci dotazů nebo indexování se běžně zobrazují. Špičky můžou nastat v reakci na indexování nebo vysoké míry dotazů, ale můžou nastat i během operací sloučení. Indexy vyhledávání se ukládají do bloků dat nebo shardů. Systém pravidelně slučuje menší fragmenty do větších fragmentů, což může pomoct optimalizovat výkon služby. Tento proces sloučení také vyčistí dokumenty, které byly dříve označené k odstranění z indexu, což vede k obnovení prostoru úložiště.

Sloučení fragmentů je rychlé, ale také náročné na zdroje, a proto může snížit výkon služby. Pokud zaznamenáte krátké nárůsty latence dotazů a tyto nárůsty se shodují s nedávnými změnami indexovaného obsahu, můžete předpokládat, že latence je způsobená operacemi sloučení fragmentů.

Další kroky

Projděte si tyto články týkající se analýzy výkonu služby.

  • Last updated on