Menganalisis performa di Azure AI Search
Artikel ini menjelaskan alat, perilaku, dan pendekatan untuk menganalisis kueri dan performa pengindeksan di Azure AI Search.
Mengembangkan angka garis besar
Dalam implementasi besar apa pun, sangat penting untuk melakukan pengujian tolok ukur performa azure AI Anda layanan Pencarian sebelum Anda menggulungnya ke produksi. Anda harus menguji beban kueri pencarian yang Anda harapkan, tetapi juga beban kerja penyerapan data yang diharapkan (jika memungkinkan, jalankan kedua beban kerja secara bersamaan). Memiliki nomor tolok ukur membantu memvalidasi tingkat pencarian yang tepat, konfigurasi layanan, dan latensi kueri yang diharapkan.
Untuk mengembangkan tolok ukur, kami merekomendasikan alat pengujian-performa-pencarian-azure (GitHub).
Untuk mengisolasi efek arsitektur layanan terdistribusi, coba uji konfigurasi layanan dari satu replika dan satu partisi.
Catatan
Untuk tingkat Penyimpanan yang Dioptimalkan (L1 dan L2), Anda harus mengharapkan throughput kueri yang lebih rendah dan latensi yang lebih tinggi daripada tingkat Standar.
Menggunakan pengelogan sumber daya
Alat diagnostik yang paling penting di pembuangan administrator adalah pengelogan sumber daya. Pengelogan sumber daya adalah kumpulan data operasional dan metrik tentang layanan pencarian Anda. Pengelogan sumber daya diaktifkan melalui Azure Monitor. Ada biaya yang terkait dengan penggunaan Azure Monitor dan menyimpan data, tetapi jika Anda mengaktifkannya untuk layanan Anda, itu bisa berperan penting dalam menyelidiki masalah performa.
Gambar berikut menunjukkan rantai peristiwa dalam permintaan dan respons kueri. Latensi dapat terjadi di salah satu dari mereka, baik selama transfer jaringan, pemrosesan konten di lapisan layanan aplikasi, atau pada layanan pencarian. Manfaat utama pengelogan sumber daya adalah bahwa aktivitas dicatat dari perspektif layanan pencarian, yang berarti bahwa log dapat membantu Anda menentukan apakah masalah performa disebabkan oleh masalah dengan kueri atau pengindeksan, atau beberapa titik kegagalan lainnya.
Pengelogan sumber daya memberi Anda opsi untuk menyimpan informasi yang dicatat. Sebaiknya gunakan Analitik Log agar Anda dapat menjalankan kueri Kusto tingkat lanjut terhadap data untuk menjawab banyak pertanyaan tentang penggunaan dan performa.
Di halaman portal layanan pencarian, Anda dapat mengaktifkan pengelogan melalui Pengaturan diagnostik, lalu menerbitkan kueri Kusto terhadap Analitik Log dengan memilih Log. Untuk informasi selengkapnya tentang penyiapan, lihat Mengumpulkan dan menganalisis data log.
Perilaku pembatasan
Pembatasan terjadi ketika layanan pencarian berada pada kapasitas. Pembatasan dapat terjadi selama kueri atau pengindeksan. Dari sisi klien, panggilan API menghasilkan respons HTTP 503 ketika telah dibatasi. Selama pengindeksan, ada juga kemungkinan menerima respons HTTP 207, yang menunjukkan bahwa satu atau beberapa item gagal diindeks. Kesalahan ini adalah indikator bahwa layanan pencarian semakin dekat dengan kapasitas.
Sebagai aturan praktis, cobalah untuk mengukur jumlah pembatasan dan pola apa pun. Misalnya, jika satu kueri pencarian dari 500.000 dibatasi, mungkin tidak layak untuk diselidiki. Namun, jika kueri dalam persentase besar dibatasi selama beberapa saat, ini akan menjadi perhatian yang lebih besar. Dengan melihat pembatasan selama beberapa saat, itu juga membantu mengidentifikasi jangka waktu di mana pembatasan akan lebih mungkin terjadi dan membantu Anda memutuskan cara terbaik untuk mengakomodasi itu.
Perbaikan sederhana untuk sebagian besar masalah pembatasan adalah membuang lebih banyak sumber daya pada layanan pencarian (biasanya replika untuk pembatasan berbasis kueri, atau partisi untuk pembatasan berbasis pengindeksan). Namun, meningkatkan replika atau partisi menambah biaya, itulah sebabnya penting untuk mengetahui alasan mengapa pembatasan terjadi sama sekali. Menyelidiki kondisi yang menyebabkan pembatasan akan dijelaskan dalam beberapa bagian berikutnya.
Di bawah ini adalah contoh kueri Kusto yang dapat mengidentifikasi uraian respons HTTP dari layanan pencarian yang telah dimuat. Selama periode 7 hari, bagan batang yang dirender menunjukkan bahwa persentase kueri pencarian yang relatif besar dibatasi, dibandingkan dengan jumlah respons yang berhasil (200).
AzureDiagnostics
| where TimeGenerated > ago(7d)
| summarize count() by resultSignature_d
| render barchart
Memeriksa pembatasan selama periode waktu tertentu dapat membantu Anda mengidentifikasi waktu di mana pembatasan mungkin lebih sering terjadi. Dalam contoh di bawah ini, bagan deret waktu digunakan untuk memperlihatkan jumlah kueri yang dibatasi yang terjadi selama jangka waktu yang ditentukan. Dalam hal ini, kueri yang dibatasi berkorelasi dengan waktu dengan tolok ukur performa dilakukan.
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
Mengukur kueri individual
Dalam beberapa kasus, mungkin berguna untuk menguji kueri individual untuk melihat performanya. Untuk melakukan ini, penting untuk dapat melihat berapa lama waktu yang dibutuhkan layanan pencarian untuk menyelesaikan pekerjaan, serta berapa lama waktu yang diperlukan untuk membuat permintaan pulang pergi dari klien dan kembali ke klien. Log diagnostik dapat digunakan untuk mencari operasi individual, tetapi mungkin lebih mudah untuk melakukan ini semua dari klien REST.
Dalam contoh di bawah ini, kueri pencarian berbasis REST dijalankan. Pencarian Azure AI menyertakan dalam setiap respons jumlah milidetik yang diperlukan untuk menyelesaikan kueri, terlihat di tab Header, dalam "waktu yang berlalu". Di samping Status di bagian atas respons, Anda akan menemukan durasi pulang pergi, dalam hal ini, 418 milidetik (ms). Di bagian hasil, tab "Header" dipilih. Dengan menggunakan kedua nilai ini, disorot dengan kotak merah pada gambar di bawah ini, kami melihat layanan pencarian membutuhkan waktu 21 ms untuk menyelesaikan kueri pencarian dan seluruh permintaan pulang pergi klien membutuhkan waktu 125 ms. Dengan mengurangi kedua angka ini, kita dapat menentukan bahwa dibutuhkan waktu tambahan 104 ms untuk mengirimkan kueri pencarian ke layanan pencarian dan untuk mentransfer hasil pencarian kembali ke klien.
Teknik ini membantu Anda mengisolasi latensi jaringan dari faktor lain yang memengaruhi performa kueri.
Laju kueri
Salah satu alasan potensial untuk layanan pencarian Anda untuk membatasi permintaan adalah karena banyaknya kueri yang dilakukan di mana volume ditangkap sebagai kueri per detik (QPS) atau kueri per menit (QPM). Karena layanan pencarian Anda menerima lebih banyak QPS, biasanya akan memakan waktu lama dan lebih lama lagi untuk menanggapi kueri tersebut sampai tidak dapat lagi mengikuti, jika begitu layanan pencarian mengirim kembali respons HTTP 503 yang membatasi.
Kueri Kusto berikut ini memperlihatkan volume kueri sebagaimana diukur dalam QPM, bersama dengan durasi rata-rata kueri dalam milidetik (AvgDurationMS) dan jumlah rata-rata dokumen (AvgDocCountReturned) yang dikembalikan di masing-masing dokumen.
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
Tip
Untuk mengungkapkan data di balik bagan ini, hapus garis | render timechart lalu jalankan ulang kueri.
Dampak pengindeksan pada kueri
Faktor penting untuk dipertimbangkan saat melihat performa adalah bahwa pengindeksan menggunakan sumber daya yang sama dengan kueri pencarian. Jika Anda mengindeks sejumlah besar konten, Anda dapat mengharapkan untuk melihat latensi tumbuh saat layanan mencoba mengakomodasi kedua beban kerja.
Jika kueri melambat, lihat waktu aktivitas pengindeksan untuk melihat apakah itu bertepatan dengan degradasi kueri. Misalnya, mungkin pengindeks menjalankan pekerjaan harian atau per jam yang berkorelasi dengan penurunan performa kueri pencarian.
Bagian ini menyediakan serangkaian kueri yang dapat membantu Anda memvisualisasikan tingkat pencarian dan pengindeksan. Untuk contoh ini, rentang waktu diatur dalam kueri. Pastikan untuk menunjukkan Atur dalam kueri saat menjalankan kueri di portal Microsoft Azure.
Latensi Kueri Rata-rata
Dalam kueri di bawah ini, ukuran interval 1 menit digunakan untuk memperlihatkan latensi rata-rata kueri pencarian. Dari bagan, kita dapat melihat bahwa latensi rata-rata rendah hingga pukul 17.45 dan berlangsung hingga 17.53.
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
Kueri Rata-Rata Per Menit (QPM)
Kueri berikut ini melihat jumlah rata-rata kueri per menit untuk memastikan bahwa tidak ada lonjakan permintaan pencarian yang mungkin memengaruhi latensi. Dari bagan, kita dapat melihat ada beberapa varians, tetapi tidak ada yang menunjukkan lonjakan jumlah permintaan.
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
Operasi Pengindeksan Per Menit (OPM)
Di sini kita akan melihat jumlah operasi Pengindeksan per menit. Dari bagan, kita dapat melihat bahwa sejumlah besar data diindeks mulai pukul 17.42 dan berakhir pada 17.50. Pengindeksan ini dimulai 3 menit sebelum kueri pencarian mulai menjadi laten dan berakhir 3 menit sebelum kueri pencarian tidak lagi laten.
Dari wawasan ini, kita dapat melihat bahwa dibutuhkan sekitar 3 menit agar layanan pencarian menjadi cukup sibuk agar pengindeksan memengaruhi latensi kueri. Kita juga dapat melihat bahwa setelah pengindeksan selesai, dibutuhkan 3 menit lagi bagi layanan pencarian untuk menyelesaikan semua pekerjaan dari konten yang baru diindeks, dan untuk mengatasi latensi kueri.
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
Pemrosesan layanan latar belakang
Tidak biasa untuk melihat lonjakan berkala dalam latensi kueri atau pengindeksan. Lonjakan mungkin terjadi sebagai respons terhadap pengindeksan atau tingkat kueri yang tinggi, tetapi juga dapat terjadi selama operasi penggabungan. Indeks pencarian disimpan dalam gugus - atau pecahan. Secara berkala, sistem menggabungkan pecahan yang lebih kecil ke dalam pecahan besar, yang dapat membantu mengoptimalkan performa layanan. Proses penggabungan ini juga membersihkan dokumen yang sebelumnya telah ditandai untuk penghapusan dari indeks, yang menghasilkan pemulihan ruang penyimpanan.
Penggabungan pecahan memang cepat, tetapi juga memerlukan sumber daya intensif dan dengan demikian berpotensi menurunkan performa layanan. Jika Anda melihat ledakan singkat latensi kueri, dan ledakan tersebut bertepatan dengan perubahan terbaru pada konten terindeks, Anda dapat mengasumsikan latensi tersebut disebabkan oleh operasi penggabungan shard.
Langkah berikutnya
Tinjau artikel ini yang terkait dengan menganalisis performa layanan.