Prestaties van een Azure AI Search-oplossing optimaliseren

Voltooid

De prestaties van uw zoekoplossingen kunnen worden beïnvloed door de grootte en complexiteit van uw indexen. U moet ook weten hoe u efficiënte query's schrijft om ernaar te zoeken en de juiste servicelaag te kiezen.

Hier verkent u al deze dimensies en ziet u de stappen die u kunt uitvoeren om de prestaties van uw zoekoplossing te verbeteren.

Uw huidige zoekprestaties meten

U kunt niet optimaliseren wanneer u niet weet hoe goed uw zoekservice presteert. Maak een benchmark voor basisprestaties, zodat u de verbeteringen kunt valideren die u aanbrengt, maar u kunt ook controleren op eventuele afname van prestaties in de loop van de tijd.

Schakel diagnostische logboekregistratie in met behulp van Log Analytics om te beginnen:

• Selecteer diagnostische instellingen in Azure Portal.
• Selecteer + Diagnostische instellingen toevoegen.

• Geef uw diagnostische instelling een naam.
• Selecteer allLogs en AllMetrics.
• Selecteer Verzenden naar Log Analytics-werkruimte.
• Kies of maak uw Log Analytics-werkruimte.

Het is belangrijk om deze diagnostische gegevens vast te leggen op het niveau van de zoekservice. Omdat er verschillende plaatsen zijn waar uw eindgebruikers of apps prestatieproblemen kunnen zien.

Als u kunt bewijzen dat uw zoekservice goed presteert, kunt u deze elimineren uit de mogelijke factoren als u prestatieproblemen ondervindt.

Controleer of uw zoekservice is beperkt

Azure AI Search-zoekopdrachten en -indexen kunnen worden beperkt. Als uw gebruikers of apps hun zoekopdrachten beperken, wordt deze vastgelegd in Log Analytics met een HTTP-antwoord van 503. Als uw indexen worden beperkt, worden deze weergegeven als 207 HTTP-antwoorden.

Deze query die u kunt uitvoeren op basis van de logboeken van de zoekservice, laat zien of uw zoekservice wordt beperkt.

Selecteer logboeken in Azure Portal onder Bewaking. Op het tabblad Nieuwe query 1 gebruikt u deze query:

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

U voert de opdracht uit om een staafdiagram van de HTTP-antwoorden van uw zoekservices weer te geven. In het bovenstaande ziet u dat er verschillende 503 antwoorden zijn geweest.

De prestaties van afzonderlijke query's controleren

De beste manier om afzonderlijke queryprestaties te testen, is met een clienthulpprogramma zoals Postman. U kunt elk hulpprogramma gebruiken waarmee u de headers in het antwoord op een query kunt weergeven. Azure AI Search retourneert altijd een 'verstreken tijd'-waarde voor hoe lang het duurde voordat de service de query heeft voltooid.

Als u wilt weten hoe lang het duurt om het antwoord van de client te verzenden en vervolgens te ontvangen, trekt u de verstreken tijd af van de totale retour. In het bovenstaande zou dat 125 ms - 21 ms zijn die u 104 ms geven.

De indexgrootte en het schema optimaliseren

Hoe uw zoekquery's presteren, is rechtstreeks verbonden met de grootte en complexiteit van uw indexen. Hoe kleiner en beter uw indexen zijn, de snelle Azure AI Search kan reageren op query's. Hier volgen enkele tips die u kunnen helpen als u hebt vastgesteld dat u prestatieproblemen hebt met afzonderlijke query's.

Als u geen aandacht besteedt, kunnen indexen na verloop van tijd groeien. Controleer of alle documenten in uw index nog steeds relevant zijn en doorzoekbaar moeten zijn.

Als u geen documenten kunt verwijderen, kunt u de complexiteit van het schema verminderen? Hebt u nog steeds dezelfde velden nodig om doorzoekbaar te zijn? Hebt u nog steeds alle vaardigheden nodig waarmee u de index hebt gestart?

Overweeg alle kenmerken te bekijken die u voor elk veld hebt ingeschakeld. Als u bijvoorbeeld ondersteuning toevoegt voor filters, facetten en sorteren, kan de opslag die nodig is om uw index te ondersteunen, viervoudig zijn.

Notitie

Als u te veel kenmerken voor een veld hebt, worden de mogelijkheden beperkt. In een veld dat bijvoorbeeld facetabel, filterbaar en doorzoekbaar is, kunt u slechts 16 kB opslaan. Terwijl een doorzoekbaar veld maximaal 16 MB aan tekst kan bevatten.

Als uw index is geoptimaliseerd, maar de prestaties nog steeds niet waar deze zich moeten bevinden, kunt u ervoor kiezen om uw zoekservice omhoog of uit te schalen.

De prestaties van uw query's verbeteren

Als u weet hoe de zoekservice werkt, kunt u uw query's afstemmen om de prestaties drastisch te verbeteren. Gebruik deze controlelijst voor het schrijven van betere query's:

1. Geef alleen de velden op die u moet doorzoeken met behulp van de parameter searchFields . Naarmate meer velden extra verwerking vereisen.
2. Retourneert het kleinste aantal velden dat u moet weergeven op de pagina met zoekresultaten. Het retourneren van meer gegevens kost meer tijd.
3. Vermijd gedeeltelijke zoektermen, zoals zoeken in voorvoegsels of reguliere expressies. Dit soort zoekopdrachten zijn rekenkundig duurder.
4. Vermijd het gebruik van waarden voor hoge skip. Dit dwingt de zoekmachine om grotere hoeveelheden gegevens op te halen en te rangschikken.
5. Beperk het gebruik van facetable- en filterbare velden tot lage kardinaliteitsgegevens.
6. Gebruik zoekfuncties in plaats van afzonderlijke waarden in filtercriteria. U kunt search.in(userid, '123,143,563,121',',') bijvoorbeeld in plaats van $filter=userid eq 123 or userid eq 143 or userid eq 563 or userid eq 121.

Als u alle bovenstaande query's hebt toegepast en nog steeds afzonderlijke query's hebt die niet worden uitgevoerd, kunt u de index uitschalen. Afhankelijk van de servicelaag die u hebt gebruikt om uw zoekoplossing te maken, kunt u maximaal 12 partities toevoegen. Partities zijn de fysieke opslag waar uw index zich bevindt. Standaard worden alle nieuwe zoekindexen gemaakt met één partitie. Als u meer partities toevoegt, wordt de index erin opgeslagen. Als uw index bijvoorbeeld 200 GB is en u vier partities hebt, bevat elke partitie 50 GB van uw index.

Het toevoegen van extra partities kan helpen bij prestaties omdat de zoekmachine parallel in elke partitie kan worden uitgevoerd. De beste verbeteringen zijn te zien voor query's die grote aantallen documenten en query's retourneren die gebruikmaken van facetten die aantallen bieden voor grote aantallen documenten. Dit is een factor van hoe rekenkundig duur het is om de relevantie van documenten te beoordelen.

Gebruik de beste servicelaag voor uw zoekbehoeften

U hebt gezien dat u servicelagen kunt uitschalen door meer partities toe te voegen. U kunt uitschalen met replica's als u wilt schalen vanwege een toename van de belasting. U kunt uw zoekservice ook omhoog schalen met behulp van een hogere laag.

De bovenstaande twee zoekindexen zijn 200 GB groot. De S1-laag maakt gebruik van acht partities en de S2-laag heeft slechts twee. Beide hebben twee replica's en beide kosten ongeveer hetzelfde. Als u de beste laag voor uw zoekoplossing kiest, moet u de geschatte totale opslaggrootte weten die u nodig hebt. De grootste index die momenteel wordt ondersteund, is 12 partities in de L2-laag met in totaal 24 TB.

Laag	Type	Storage	Replica's	Partities
F	Gratis	50 MB	1	1
B	Basis	2 GB	3	1
S1	Standaard	25 GB/partitie	12	12
S2	Standaard	100 GB/partitie	12	12
S3	Standaard	200 GB/partitie	12	12
S3HD	High-density	200 GB/partitie	12	3
L1	Geoptimaliseerde opslag	1 TB/partitie	12	12
L2	Geoptimaliseerde opslag	2 TB/partitie	12	12

Welke van de bovenstaande twee lagen in het bovenstaande voorbeeld vindt u het beste? U hebt gezien dat uitschalen prestatievoordelen biedt vanwege parallelle uitvoering. De hogere lagen worden echter ook geleverd met Premium Storage, krachtigere rekenresources en extra geheugen. Als u de tweede optie kiest, beschikt u over een krachtigere infrastructuur en kunt u toekomstige indexgroei mogelijk maken. Welke laag het beste presteert, is helaas afhankelijk van de grootte en complexiteit van uw index en de query's die u schrijft om ernaar te zoeken. Dus beide kunnen het beste zijn.

Het plannen van toekomstige groei in het gebruik van uw zoekoplossing betekent dat u zoekeenheden moet overwegen. Een zoekeenheid (SU) is het product van replica's en partities. Dat betekent dat de bovenstaande S1-laag 16 SU gebruikt en dat de S2-laag slechts 4 SU is. De kosten zijn vergelijkbaar met hogere lagen die meer per SU in rekening brengen.

Denk na over het schalen van uw zoekoplossing vanwege de toegenomen belasting. Als u nog een replica toevoegt aan beide lagen, wordt de S1-laag verhoogd naar 24 SU , maar de S2-laag stijgt alleen tot 6 SU.