Teljesítmény elemzése az Azure AI Keresésben

Ez a cikk az Azure AI Keresés lekérdezési és indexelési teljesítményének elemzéséhez szükséges eszközöket, viselkedéseket és megközelítéseket ismerteti.

Ez a cikk csak a klasszikus, teljes szöveges keresési forgatókönyvekre vonatkozik.

Alapkonfigurációs számok fejlesztése

Minden nagy implementációban kritikus fontosságú az Azure AI-Search szolgáltatás teljesítménymérési tesztjének végrehajtása, mielőtt éles környezetbe helyeznénk. Tesztelnie kell a keresési lekérdezés várt terhelését, de a várt adatbetöltési számítási feladatokat is (ha lehetséges, mindkét számítási feladatot egyszerre kell futtatnia). A teljesítménymutató-számok segítségével ellenőrizheti a megfelelő keresési szintet, a szolgáltatáskonfigurációt és a lekérdezések várható késését.

Az elosztott szolgáltatásarchitektúra hatásainak elkülönítéséhez próbálkozzon egy replika és egy partíció szolgáltatáskonfigurációinak tesztelésével.

Erőforrásnaplózás használata

A rendszergazda számára a legfontosabb diagnosztikai eszköz az erőforrás-naplózás. Az erőforrásnaplózás a keresési szolgáltatással kapcsolatos operatív adatok és metrikák gyűjteménye. Az erőforrásnaplózás az Azure Monitoron keresztül engedélyezve van. Az Azure Monitor használatával és az adatok tárolásával kapcsolatos költségek merülnek fel, de ha engedélyezi a szolgáltatás számára, az fontos szerepet kaphat a teljesítményproblémák kivizsgálásában.

Az alábbi képen egy lekérdezési kérelem és válasz eseménylánca látható. A késés bármelyiküknél előfordulhat, legyen szó hálózati átvitelről, tartalom feldolgozásáról az App Services-rétegben vagy egy keresési szolgáltatásban. Az erőforrásnaplózás egyik fő előnye, hogy a tevékenységek a keresési szolgáltatás szempontjából vannak naplózva, ami azt jelenti, hogy a napló segíthet megállapítani, hogy a teljesítményproblémát a lekérdezéssel vagy indexeléssel kapcsolatos problémák vagy más meghibásodási pontok okozták-e.

Az erőforrásnaplózás lehetővé teszi a naplózott adatok tárolását. A Log Analytics használatát javasoljuk, hogy speciális Kusto-lekérdezéseket hajthat végre az adatokon, hogy megválaszolhassa a használattal és a teljesítménnyel kapcsolatos számos kérdést.

A keresési szolgáltatás portál oldalain engedélyezheti a naplózást a diagnosztikai beállításokon keresztül, majd Kusto-lekérdezéseket adhat ki a Log Analyticshez a Naplók kiválasztásával. Ha meg szeretné tudni, hogyan küldhet erőforrásnaplókat egy Log Analytics-munkaterületre, ahol napló lekérdezésekkel elemezheti őket, tekintse meg az Azure-erőforrások erőforrásnaplóinak gyűjtését és elemzését.

Korlátozási viselkedések

A szabályozás akkor következik be, ha a keresési szolgáltatás eléri a kapacitását. Az lassítás a lekérdezések vagy indexelés során fordulhat elő. Az ügyféloldalon egy API-hívás 503 HTTP-választ eredményez, ha korlátozták. Az indexelés során 207 HTTP-választ is kaphat, ami azt jelzi, hogy egy vagy több elem indexelése sikertelen volt. Ez a hiba azt jelzi, hogy a keresési szolgáltatás egyre közelebb kerül a kapacitáshoz.

Ökölszabályként próbálja meg számszerűsíteni a korlátozások mértékét és az esetleges mintázatokat. Például, ha 500 000 keresési lekérdezés közül csak egy van korlátozva, akkor lehet, hogy nem érdemes azt kivizsgálni. Ha azonban a lekérdezések nagy százaléka korlátozva van egy adott időszakban, ez nagyobb problémát jelent. Az időszakos korlátozások vizsgálatával azonosíthatók azok az időkeretek is, amikor valószínűbb a korlátozás bekövetkezése, és segít eldönteni, hogyan alkalmazkodhatunk ehhez a legjobban.

A legtöbb szabályozással kapcsolatos probléma egyszerű megoldása, ha több erőforrást ad a keresési szolgáltatásnak (általában a lekérdezésalapú szabályozás replikáit vagy az indexelési alapú szabályozás partícióit). A replikák vagy partíciók számának növelése azonban költséggel jár, ezért fontos tudni, hogy egyáltalán miért történik szabályozás. A szabályozást kiváltó feltételek vizsgálatának ismertetése a következő néhány szakaszban lesz ismertetve.

Az alábbi példa egy Kusto-lekérdezésre mutat be, amely képes azonosítani a betöltés alatt álló keresési szolgáltatás HTTP-válaszainak lebontását. A sikeres (200) válaszok számához képest a renderelt sávdiagram egy 7 napos időszak alatt azt mutatja be, hogy a keresési lekérdezések viszonylag nagy százaléka korlátozva volt.

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

Egy adott időszak szabályozásának vizsgálata segíthet azonosítani azokat az időket, amikor a szabályozás gyakrabban fordulhat elő. Az alábbi példában egy idősordiagramot használunk a megadott időkereten keresztül végrehajtott szabályozott lekérdezések számának megjelenítésére. Ebben az esetben a korlátozott lekérdezések összefüggtek azokkal az időpontokkal, amikor a teljesítménymérés történt.

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   

Egyedi lekérdezések mérése

Bizonyos esetekben hasznos lehet az egyes lekérdezések tesztelése, hogy lássák, hogyan teljesítenek. Ehhez fontos látni, hogy a keresési szolgáltatás mennyi ideig tart a munka befejezéséhez, valamint hogy mennyi ideig tart az ügyféltől és az ügyféltől visszafelé irányuló oda-vissza kérés végrehajtása. A diagnosztikai naplók felhasználhatók az egyes műveletek keresésére, de egyszerűbb lehet mindezt egy REST-ügyfélből elvégezni.

Az alábbi példában egy REST-alapú keresési lekérdezés lett végrehajtva. Az Azure AI Keresés minden válaszban feltünteti a lekérdezés befejezéséhez szükséges ezredmásodpercek számát, amely a Fejlécek fülön, az "elapsed-time" mezőben látható. A válasz tetején található Állapot mellett megtalálja az oda-vissza utazás időtartamát, ebben az esetben 125 ezredmásodpercet (ms). Az eredmények szakaszban a "Fejlécek" lap lett kiválasztva. Az alábbi képen egy piros mezővel kiemelt két érték alapján látható, hogy a keresési szolgáltatás 21 ms-ot vett igénybe a keresési lekérdezés befejezéséhez, és a teljes ügyfél-oda-vissza kérés 125 ms-ot vett igénybe. A két szám kivonásával megállapíthatjuk, hogy 104 ms-tal több időt vett igénybe a keresési lekérdezés továbbítása a keresési szolgáltatásnak, és a keresési eredmények átvitele az ügyfélnek.

Ez a technika segít elkülöníteni a hálózati késéseket a lekérdezési teljesítményt befolyásoló egyéb tényezőktől.

Lekérdezési arányok

A keresési szolgáltatás kéréseinek szabályozására az egyik lehetséges ok a lekérdezések nagy száma, melyet a rendszer másodpercenkénti (QPS) vagy percenkénti (QPM) lekérdezésszámként rögzíthet. Amint a keresési szolgáltatás egyre több QPS-t kap, általában egyre tovább tart majd válaszolni ezekre a lekérdezésekre, amíg már nem tud lépést tartani, amely során 503-as HTTP korlátozó választ küld vissza.

Az alábbi Kusto-lekérdezés a QPM-ben mért lekérdezéskötetet, valamint egy lekérdezés átlagos időtartamát mutatja ezredmásodpercben (AvgDurationMS) és az egyes visszaadott dokumentumok átlagos számát (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

Az indexelés hatása a lekérdezésekre

A teljesítmény tekintetében fontos figyelembe venni, hogy az indexelés ugyanazokat az erőforrásokat használja, mint a keresési lekérdezések. Ha nagy mennyiségű tartalmat indexel, várható, hogy a késés növekedni fog, mivel a szolgáltatás mindkét számítási feladatot megpróbálja kezelni.

Ha a lekérdezések lelassulnak, tekintse meg az indexelési tevékenység időzítését annak megállapításához, hogy egybeesik-e a lekérdezések romlásával. Előfordulhat például, hogy egy indexelő napi vagy óránkénti feladatot futtat, amely korrelál a keresési lekérdezések csökkent teljesítményével.

Ez a szakasz lekérdezések készletét tartalmazza, amelyek segíthetnek a keresési és indexelési arányok megjelenítésében. Ezekben a példákban az időtartomány a lekérdezésben van beállítva. A lekérdezések Azure Portalon való futtatásakor mindenképpen adja meg a Set in query (Beállítás a lekérdezésben) lehetőséget.

Lekérdezések átlagos késése

Az alábbi lekérdezésben az 1 perces intervallumméret a keresési lekérdezések átlagos késésének megjelenítésére szolgál. A diagramon látható, hogy az átlagos késés 17:45-ig alacsony volt, és 17:53-ig tartott.

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

Átlagos lekérdezések percenként (QPM)

Az alábbi lekérdezés a lekérdezések percenkénti átlagos számát vizsgálja annak biztosítása érdekében, hogy a keresési kérelmek nem voltak olyan csúcsértékek, amelyek befolyásolhatták volna a késést. A diagramon látható némi eltérés, de semmi sem utal a kérések számának megugrására.

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

Indexelési műveletek percenként (OPM)

Itt az indexelési műveletek percenkénti számát tekintjük át. A diagramon látható, hogy nagy mennyiségű adat indexelése 17:42-kor kezdődött, és 17:50-kor ért véget. Ez az indexelés 3 perccel azelőtt kezdődött, hogy a keresési lekérdezések látenssé váltak, és 3 perccel azelőtt fejeződött be, hogy a keresési lekérdezések már nem voltak látensek.

Ebből a megállapításból látható, hogy körülbelül 3 percig tartott, amíg a keresési szolgáltatás foglalttá vált ahhoz, hogy az indexelés hatással legyen a lekérdezés késésére. Azt is láthatjuk, hogy az indexelés befejezése után további 3 percig tartott, amíg a keresési szolgáltatás befejezte az újonnan indexelt tartalomból származó összes munkát, és hogy a lekérdezés késése megoldódjon.

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 

Háttérszolgáltatás feldolgozása

Gyakori, hogy időnként megugrik a lekérdezési vagy indexelési késés. A kiugró értékek indexelés vagy magas lekérdezési arány esetén fordulhatnak elő, de az egyesítési műveletek során is előfordulhatnak. A keresési indexek adattömbökben vagy szegmensekben vannak tárolva. A rendszer időnként kisebb szegmenseket egyesít nagy szegmensekké, ami segíthet a szolgáltatás teljesítményének optimalizálásában. Ez az egyesítési folyamat a korábban törlésre megjelölt dokumentumokat is törli az indexből, ami a tárterület helyreállítását eredményezi.

A szegmensek egyesítése gyors, de erőforrásigényes is, így csökkentheti a szolgáltatás teljesítményét. Ha rövid lekérdezési késést észlel, és ezek a kipukkadások egybeesnek az indexelt tartalom legutóbbi változásaival, feltételezheti, hogy a késés a szegmensek egyesítési műveleteinek köszönhető.

Következő lépések

Tekintse át a szolgáltatás teljesítményének elemzésével kapcsolatos cikkeket.

• Teljesítménnyel kapcsolatos tippek
• Szolgáltatási szint kiválasztása
• Kapacitás kezelése
• Esettanulmány: Összetett AI-forgatókönyvek támogatása a Cognitive Search használatával