Azure AI Search'te performansı analiz etme

Bu makalede, Azure AI Search'te sorgu ve dizin oluşturma performansını analiz etmek için kullanılan araçlar, davranışlar ve yaklaşımlar açıklanmaktadır.

Taban çizgisi numaraları geliştirme

Tüm büyük uygulamalarda, azure yapay zeka Arama hizmeti üretim aşamasına geçirmeden önce performans karşılaştırma testi yapmak kritik önem taşır. Hem beklediğiniz arama sorgusu yükünü hem de beklenen veri alımı iş yüklerini test etmelisiniz (mümkünse her iki iş yükünü de aynı anda çalıştırın). Karşılaştırma numaralarına sahip olmak uygun arama katmanını, hizmet yapılandırmasını ve beklenen sorgu gecikme süresini doğrulamaya yardımcı olur.

Karşılaştırmalar geliştirmek için azure-search-performance-testing (GitHub) aracını öneririz.

Dağıtılmış hizmet mimarisinin etkilerini yalıtmak için, bir çoğaltmanın ve bir bölümün hizmet yapılandırmalarını test etmeyi deneyin.

Kaynak günlüğünü kullanma

Bir yöneticinin kullanımındaki en önemli tanılama aracı kaynak günlüğüdür. Kaynak günlüğü, arama hizmetinizle ilgili operasyonel verilerin ve ölçümlerin toplanmasıdır. Kaynak günlüğü Azure İzleyici aracılığıyla etkinleştirilir. Azure İzleyici'yi kullanma ve verileri depolamayla ilgili maliyetler vardır, ancak hizmetiniz için etkinleştirirseniz performans sorunlarını araştırmak yararlı olabilir.

Aşağıdaki görüntüde sorgu isteği ve yanıttaki olaylar zinciri gösterilmektedir. Ağ aktarımı sırasında, uygulama hizmetleri katmanındaki içeriğin işlenmesinde veya bir arama hizmetinde gecikme süresi oluşabilir. Kaynak günlüğünün temel avantajlarından biri, etkinliklerin arama hizmeti perspektifinden günlüğe kaydedilmesidir; bu da günlüğün performans sorununun sorgu veya dizin oluşturma ile ilgili sorunlardan mı yoksa başka bir hata noktasından mı kaynaklandığını belirlemenize yardımcı olabileceği anlamına gelir.

Kaynak günlüğü, günlüğe kaydedilen bilgileri depolama seçenekleri sunar. Kullanım ve performansla ilgili birçok soruyu yanıtlamak üzere verilere karşı gelişmiş Kusto sorguları yürütebilmeniz için Log Analytics'i kullanmanızı öneririz.

Arama hizmeti portalı sayfalarınızda Tanılama ayarları aracılığıyla günlüğe kaydetmeyi etkinleştirebilir ve ardından Günlükler'i seçerek Log Analytics'te Kusto sorguları oluşturabilirsiniz. Kaynak günlüklerini günlük sorguları ile çözümleyebileceğiniz bir Log Analytics çalışma alanına göndermeyi öğrenmek için bkz . Azure kaynağından kaynak günlüklerini toplama ve analiz etme.

Azaltma davranışları

Azaltma, arama hizmeti kapasitede olduğunda gerçekleşir. Azaltma, sorgular veya dizin oluşturma sırasında oluşabilir. İstemci tarafında, bir API çağrısı kısıtlandığında 503 HTTP yanıtıyla sonuçlanmıştır. Dizin oluşturma sırasında, bir veya daha fazla öğenin dizine alınamadığına işaret eden 207 HTTP yanıtı alma olasılığı da vardır. Bu hata, arama hizmetinin kapasiteye yaklaştığını gösteren bir göstergedir.

Bir kural olarak, azaltma miktarını ve herhangi bir deseni ölçmeye çalışın. Örneğin, 500.000 arama sorgusundan biri kısıtlanırsa araştırmaya değmeyebilir. Ancak, sorguların büyük bir yüzdesi bir süre içinde kısıtlanırsa, bu daha büyük bir endişe olacaktır. Bir süre boyunca azaltmaya bakarak, azaltmanın oluşma olasılığının daha yüksek olduğu zaman çerçevelerini belirlemenize ve buna en iyi uyumu nasıl belirleyeceğinize karar vermenize yardımcı olur.

Çoğu azaltma sorununun basit bir düzeltmesi, arama hizmetine daha fazla kaynak (genellikle sorgu tabanlı azaltma için çoğaltmalar veya dizin tabanlı azaltma için bölümler) oluşturmaktır. Ancak çoğaltmaların veya bölümlerin artırılması maliyet kazandırır. Bu nedenle azaltmanın neden olduğunu bilmeniz önemlidir. Azaltmaya neden olan koşulları araştırmak, sonraki birkaç bölümde açıklanacaktır.

Aşağıda, yük altında olan arama hizmetinden HTTP yanıtlarının dökümünü belirleyebilen bir Kusto sorgusu örneği verilmiştir. 7 günlük bir süre boyunca, işlenen çubuk grafik, başarılı (200) yanıt sayısına kıyasla arama sorgularının nispeten büyük bir yüzdesinin kısıtlandığını gösterir.

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

Belirli bir zaman aralığında azaltmayı incelemek, azaltmanın daha sık gerçekleşebileceği saatleri belirlemenize yardımcı olabilir. Aşağıdaki örnekte, belirli bir zaman diliminde gerçekleşen kısıtlanmış sorguların sayısını göstermek için bir zaman serisi grafiği kullanılır. Bu durumda, azaltılan sorgular performans karşılaştırması ile içindeki sürelerle bağıntılı olarak gerçekleştirildi.

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   

Tek tek sorguları ölçme

Bazı durumlarda, nasıl performans gösterdiklerini görmek için tek tek sorguları test etmek yararlı olabilir. Bunu yapmak için, arama hizmetinin işi tamamlamasının ne kadar sürdüğünü ve istemciden geri dönüş isteğinin ne kadar sürdüğünü görebilmek önemlidir. Tanılama günlükleri tek tek işlemleri aramak için kullanılabilir, ancak bunların tümünü rest istemcisinden yapmak daha kolay olabilir.

Aşağıdaki örnekte REST tabanlı bir arama sorgusu yürütüldü. Azure AI Search, her yanıtta sorguyu tamamlamak için gereken milisaniye sayısını (Üst Bilgiler sekmesindeki "geçen süre" içinde görünür) içerir. Yanıtın üst kısmındaki Durum'un yanında gidiş dönüş süresini (bu örnekte 418 milisaniye (ms) bulabilirsiniz. Sonuçlar bölümünde "Üst Bilgiler" sekmesi seçilmiştir. Aşağıdaki resimde kırmızı bir kutuyla vurgulanan bu iki değeri kullanarak, arama hizmetinin arama sorgusunu tamamlaması 21 ms sürdüğünü ve istemci gidiş dönüş isteğinin tamamının 125 ms sürdüğünü görüyoruz. Bu iki sayıyı çıkararak, arama sorgusunu arama hizmetine iletmenin ve arama sonuçlarının istemciye geri aktarılmasının 104 ms ek zaman aldığını belirleyebiliriz.

Bu teknik, ağ gecikme sürelerini sorgu performansını etkileyen diğer faktörlerden yalıtmanıza yardımcı olur.

Sorgu oranları

Arama hizmetinizin istekleri azaltmasının olası nedenlerinden biri, birimin saniye başına sorgu (QPS) veya dakika başına sorgu (QPM) olarak yakalandığı çok sayıda sorgudan kaynaklanır. Arama hizmetiniz daha fazla QPS aldığından, bu sorguların yanıt vermesi normalde daha uzun ve daha uzun sürer. Bu işlem artık devam edemez ve azaltma 503 HTTP yanıtını geri gönderir.

Aşağıdaki Kusto sorgusu, bir sorgunun milisaniye cinsinden ortalama süresi (AvgDurationMS) ve her birinde döndürülen ortalama belge sayısı (AvgDocCountReturned) ile birlikte QPM'de ölçülen sorgu hacmini gösterir.

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

Dizin oluşturmanın sorgular üzerindeki etkisi

Performansa bakarken dikkate alınması gereken önemli bir faktör, dizin oluşturmanın arama sorguları ile aynı kaynakları kullanmasıdır. Büyük miktarda içeriğin dizinini oluştururken hizmet her iki iş yükünü de barındırmaya çalışırken gecikme süresinin artmasını bekleyebilirsiniz.

Sorgular yavaşlarsa, dizin oluşturma etkinliğinin zamanlamasına bakarak sorgu düşüşüyle aynı olup olmadığını denetleyin. Örneğin, bir dizin oluşturucu, arama sorgularının performansının düşmesiyle bağıntılı günlük veya saatlik bir iş çalıştırıyor olabilir.

Bu bölüm, arama ve dizin oluşturma oranlarını görselleştirmenize yardımcı olabilecek bir dizi sorgu sağlar. Bu örnekler için zaman aralığı sorguda ayarlanır. Sorguları Azure portalında çalıştırırken Sorguda ayarla seçeneğini belirttiğinizden emin olun.

Ortalama Sorgu Gecikme Süresi

Aşağıdaki sorguda, arama sorgularının ortalama gecikme süresini göstermek için 1 dakikalık bir aralık boyutu kullanılır. Grafikten ortalama gecikme süresinin 17:45'e kadar düşük olduğunu ve 17:53'e kadar sürdüğünü görebiliriz.

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

Dakika Başına Ortalama Sorgu Sayısı (QPM)

Aşağıdaki sorgu, arama isteklerinde gecikme süresini etkilemiş olabilecek ani bir artış olmadığından emin olmak için dakikada ortalama sorgu sayısına bakar. Grafikten, bazı varyanslar olduğunu görebiliriz, ancak istek sayısındaki ani artışa işaret eden hiçbir şey yoktur.

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

Dakika Başına Dizin oluşturma İşlemleri (OPM)

Burada dakika başına dizin oluşturma işlemlerinin sayısına bakacağız. Grafikten, büyük miktarda verinin 17:42'de başlayıp 17:50'de sona erdiğini görebiliriz. Bu dizin oluşturma, arama sorgularının gecikmeye başlamasından 3 dakika önce başladı ve arama sorguları artık gizli kalmadan 3 dakika önce sona erdi.

Bu içgörüden, arama hizmetinin dizin oluşturmanın sorgu gecikmesini etkilemesi için yeterince meşgul hale gelmesinin yaklaşık 3 dakika sürdüğünü görebiliriz. Ayrıca dizin oluşturma tamamlandıktan sonra arama hizmetinin yeni dizine alınan içerikten tüm çalışmaları tamamlamasının ve sorgu gecikme süresinin çözülmesinin 3 dakika daha sürdüğünü görebiliriz.

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 

Arka plan hizmeti işleme

Sorgu veya dizin oluşturma gecikmesinde düzenli ani artışlar görmek olağan dışı değildir. Ani artışlar dizin oluşturma veya yüksek sorgu hızlarına yanıt olarak oluşabilir, ancak birleştirme işlemleri sırasında da oluşabilir. Arama dizinleri öbekler veya parçalar halinde depolanır. Sistem düzenli aralıklarla küçük parçaları büyük parçalar halinde birleştirir ve bu da hizmet performansını iyileştirmeye yardımcı olabilir. Bu birleştirme işlemi, daha önce dizinden silinmek üzere işaretlenmiş belgeleri de temizleyerek depolama alanının kurtarılmasını sağlar.

Parçaları birleştirmek hızlıdır, ancak aynı zamanda yoğun kaynak kullanır ve bu nedenle hizmet performansını düşürme potansiyeline sahiptir. Kısa süreli sorgu gecikmesi fark ederseniz ve bu ani artışlar dizine alınan içerikte yapılan son değişikliklerle çakışıyorsa, gecikme süresinin parça birleştirme işlemlerinden kaynaklandığı varsayabilirsiniz.

Sonraki adımlar

Hizmet performansını analiz etmeyle ilgili bu makaleleri gözden geçirin.

• Performans ipuçları
• Hizmet katmanı seçme
• Kapasiteyi yönetme
• Örnek Olay İncelemesi: Karmaşık Yapay Zeka Senaryolarını Desteklemek için Bilişsel Arama Kullanma