Teljesítmény elemzése az Azure AI Searchben
Ez a cikk az Azure AI Search 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.
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.
A teljesítménytesztek fejlesztéséhez az Azure-search-performance-testing (GitHub) eszközt javasoljuk.
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.
Feljegyzés
A Tárolási optimalizált szintek (L1 és L2) esetében alacsonyabb lekérdezési átviteli sebességre és nagyobb késésre kell számítania, mint a Standard szintek.
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. A beállítással kapcsolatos további információkért lásd a naplóadatok gyűjtését és elemzését.
Szabályozási viselkedések
A szabályozás akkor történik, ha a keresési szolgáltatás kapacitásban van. A szabályozá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 szabályoztá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 szabályozás és a minták mennyiségét. Ha például 500 000-ből egy keresési lekérdezés szabályozva van, nem érdemes kivizsgálni. Ha azonban a lekérdezések nagy százaléka szabályozva van egy adott időszakban, ez nagyobb problémát jelent. Ha egy adott időszak szabályozását nézzük, az is segít azonosítani azokat az időkereteket, amelyeknél nagyobb valószínűséggel fordul elő szabályozás, és segít eldönteni, hogyan lehet ezt a legjobban kielégíteni.
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. Egy 7 napos időszak alatt a renderelt sávdiagram azt mutatja, hogy a keresési lekérdezések viszonylag nagy százaléka szabályozva lett a sikeres (200) válaszok számához képest.
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 szabályozott lekérdezések korrelálnak a teljesítmény-teljesítményértékeléshez kapcsolódó időkkel.
let ['_startTime']=datetime('2021-02-25T20:45:07Z');
let ['_endTime']=datetime('2021-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 Search minden válaszban tartalmazza a lekérdezés befejezéséhez szükséges ezredmásodpercek számát, amely a Fejlécek lapon látható, az "eltelt idő" alatt látható. A válasz tetején található Állapot mellett megtalálja az oda-vissza utazás időtartamát, ebben az esetben 418 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 a kérések szabályozásának egyik lehetséges oka az, hogy a rendszer a másodpercenkénti lekérdezések (QPS) vagy a percenkénti lekérdezések (QPM) mennyiségeként rögzített lekérdezések számát tekinti meg. Mivel a keresési szolgáltatás több QPS-t kap, általában tovább és tovább tart válaszolni ezekre a lekérdezésekre, amíg nem tud lépést tartani, mivel az 503-as szabályozású HTTP-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
Tipp.
A diagram mögötti adatok megjelenítéséhez távolítsa el a vonalat | render timechart , majd futtassa újra a lekérdezést.
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('2021-02-23 17:40');
let _endTime = datetime('2021-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('2021-02-23 17:40');
let _endTime = datetime('2021-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('2021-02-23 17:40');
let _endTime = datetime('2021-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
Nem szokatlan, hogy a lekérdezési vagy indexelési késés rendszeres kiugróan magas. 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.