Azure Yapay Zeka Arama'te performansı analiz etme

Note

Azure Yapay Zeka Arama Azure portalı, REST API'leri ve Azure SDK’ları aracılığıyla kullanılabilir. Ayrıca kuruluş içeriğini Microsoft Foundry portalındaki aracılar için yeniden kullanılabilir, izin kullanan bilgi bankalarına dönüştüren yönetilen bilgi katmanı Foundry IQ'yu temel alır.

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

Bu makale yalnızca klasik arama, tam metin arama senaryoları için geçerlidir.

Temel sayı 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.

Dağıtılmış bir hizmet mimarisinin etkilerini izole etmek için, bir replika ve bir bölüm yapılandırmalarında test yapmayı deneyin.

Note

Depolama için İyileştirilmiş katmanlar (L1 ve L2) için, standart katmanlardan daha düşük sorgu aktarım hızı ve daha yüksek gecikme süresi beklemelisiniz.

Kaynak günlüğünü kullanın

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.

Günlüğe kaydedilen olaylar zinciri

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 Günlükler’i seçerek Log Analytics'te Kusto sorguları oluşturabilirsiniz. Kaynak günlüklerini bir Log Analytics çalışma alanına göndererek günlük sorguları ile analiz etmeyi öğrenmek için bkz Azure kaynağından kaynak günlüklerini toplama ve analiz etme.

Sınırlama davranışları

Azaltma, arama hizmeti kapasitesine ulaştığında 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ı verir. 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.

Genel bir kural olarak, azaltma miktarını ve herhangi bir modeli ö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 kısıtlamaya bakarak, kısıtlamanın daha olası olduğu zaman dilimlerini belirlemenize ve buna en iyi şekilde nasıl uyum sağlayabileceğinize karar vermenize yardımcı olur.

Çoğu kısıtlama sorununun basit bir çözümü, arama hizmetine daha fazla kaynak sağlamak (genellikle sorgu tabanlı kısıtlama için çoğaltmalar veya dizin tabanlı kısıtlama için bölümler) olur. Ancak çoğaltmaların veya bölümlerin artırılması maliyeti artırır; bu nedenle kısıtlamanın neden gerçekleştiğini bilmek önemlidir. Hız düşürmeye neden olan koşulların araştırılması, 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 görüntülenen çubuk grafik, başarılı (200) yanıtlar 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

Http hata sayılarının çubuk grafiği

Belirli bir zaman aralığında kısıtlamayı incelemek, kısıtlamanın daha sık meydana gelebileceği zaman dilimlerini 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, sınırlı sorgular, performans kıyaslamasının yapıldığı zamanlarla bağıntılı olarak gerçekleştirildi.

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

Kısıtlanmış sorguların çizgi grafiği

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 Yapay Zeka Arama, 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 125 milisaniye (ms) bulursunuz. 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 süresi ölçümleri

Sorgu oranları

Arama hizmetinizin istekleri kısıtlamasının olası nedenlerinden biri, sorguların yoğunluk, saniye başına sorgular (QPS) veya dakika başına sorgular (QPM) olarak ölçülen yüksek sayıda sorgunun gerçekleştirilmesi sonucu ortaya çıkar. Arama hizmetiniz daha fazla QPS aldıkça, bu sorgulara yanıt vermek genellikle gittikçe daha uzun sürer. Sonunda bu hıza yetişemez hale gelir ve bunun sonucunda yavaşlatma amacıyla 503 HTTP yanıtı 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

Dakika başına sorguları gösteren grafik

Tip

Bu grafiğin arkasındaki verileri ortaya çıkarmak için çizgiyi | render timechart kaldırın ve sorguyu yeniden çalıştırın.

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. Azure portalında sorguları çalıştırırken Sorguda Ayarla seçeneğini belirttiğinizden emin olun.

Sorgu aracında zaman aralıklarını ayarlama

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('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

Ortalama sorgu gecikme süresini gösteren grafik

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('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

Dakika başına ortalama sorguları gösteren grafik

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 gecikmeli hale gelmeye başlamasından 3 dakika önce başladı ve arama sorguları artık gecikme yaşamadan 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('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

Dakika başına dizin oluşturma işlemlerini gösteren grafik

Arka plan hizmeti işleme

Sorgu veya dizin oluşturma gecikmesinde sık karşılaşılan ani artışlar görülür. 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.

  • Last updated on