Bagikan melalui

Fabric API untuk praktik terbaik performa GraphQL

API Microsoft Fabric untuk GraphQL menawarkan cara yang kuat untuk mengkueri data secara efisien, tetapi pengoptimalan performa adalah kunci untuk memastikan performa yang lancar dan dapat diskalakan. Baik Anda menangani kueri kompleks atau mengoptimalkan waktu respons, praktik terbaik berikut membantu Anda mendapatkan performa terbaik dari implementasi GraphQL Anda dan memaksimalkan efisiensi API Anda di Fabric.

Siapa yang membutuhkan pengoptimalan performa

Pengoptimalan performa sangat penting untuk:

  • Pengembang aplikasi membangun aplikasi dengan lalu lintas tinggi yang mengkueri lakehouse dan gudang Fabric
  • Teknisi data mengoptimalkan pola akses data Fabric untuk aplikasi analitik skala besar dan proses ETL
  • Admin ruang kerja Fabric mengelola konsumsi kapasitas dan memastikan pemanfaatan sumber daya yang efisien
  • Pengembang BI meningkatkan waktu respons untuk aplikasi analitik kustom yang dibangun di atas data Fabric
  • Tim DevOps memecahkan masalah latensi dalam aplikasi produksi yang menggunakan API Fabric

Gunakan praktik terbaik ini saat API GraphQL Anda perlu menangani beban kerja produksi secara efisien atau saat Anda mengalami masalah performa.

Perataan wilayah

Panggilan API lintas wilayah adalah penyebab umum latensi tinggi. Untuk performa optimal, pastikan aplikasi klien, penyewa Fabric, kapasitas, dan sumber data Anda semuanya berada di wilayah Azure yang sama.

Periksa wilayah penyewa Anda

Untuk menemukan wilayah penyewa Fabric Anda:

  1. Masuk ke portal Microsoft Fabric dengan akun admin
  2. Pilih ikon Bantuan (?) di sudut kanan atas
  3. Di bagian bawah panel Bantuan, pilih Tentang Fabric
  4. Perhatikan wilayah yang ditampilkan dalam detail penyewa

Periksa wilayah kapasitas Anda

API Anda untuk GraphQL berjalan dalam kapasitas tertentu. Untuk menemukan wilayah kapasitas:

  1. Buka ruang kerja yang menghosting API Anda untuk GraphQL

  2. Silakan menuju pengaturan Ruang Kerja>Info lisensi

  3. Temukan wilayah di bawah Kapasitas lisensi

    Cuplikan layar memperlihatkan cara mendapatkan wilayah kapasitas untuk ruang kerja Anda.

Periksa wilayah sumber data Anda

Lokasi sumber data Anda juga berdampak pada performa:

  • Sumber data Fabric (Lakehouse, Gudang Data, SQL Database): Ini menggunakan wilayah yang sama dengan kapasitas ruang kerja
  • Sumber data eksternal (Azure SQL Database, dll.): Periksa lokasi sumber daya di portal Microsoft Azure

Praktik terbaik: Sebarkan aplikasi klien di wilayah yang sama dengan kapasitas Fabric dan sumber data Anda untuk meminimalkan latensi jaringan.

Praktik terbaik pengujian performa

Saat mengevaluasi performa API Anda, ikuti panduan ini untuk hasil yang andal dan konsisten.

Menggunakan alat pengujian realistis

Uji dengan alat yang sangat cocok dengan lingkungan produksi Anda:

  • Skrip atau aplikasi: Gunakan skrip Python, Node.js, atau .NET yang mensimulasikan perilaku klien aktual
  • Pengumpulan koneksi HTTP: Gunakan kembali koneksi HTTP untuk mengurangi latensi, terutama penting untuk skenario lintas wilayah
  • Manajemen sesi: Mempertahankan sesi antar permintaan untuk mencerminkan penggunaan dunia nyata secara akurat

Sumber daya sampel:

Mengumpulkan metrik yang bermakna

Untuk penilaian performa yang akurat:

  1. Mengotomatiskan pengujian: Menggunakan skrip atau alat pengujian performa untuk menjalankan pengujian secara konsisten selama periode yang ditentukan
  2. Pemanasan API: Jalankan beberapa kueri pengujian sebelum mengukur performa (lihat Persyaratan pemanasan)
  3. Menganalisis distribusi: Menggunakan metrik berbasis persentil (P50, P95, P99) daripada hanya rata-rata untuk memahami pola latensi
  4. Uji di bawah beban: Mengukur performa dengan volume permintaan bersamaan yang realistis
  5. Kondisi dokumen: Catat waktu hari, pemanfaatan kapasitas, dan beban kerja bersamaan selama pengujian

Masalah performa umum

Memahami masalah umum ini membantu Anda mendiagnosis dan menyelesaikan masalah performa secara efektif.

Persyaratan pemanasan

Masalah: Permintaan API pertama membutuhkan waktu jauh lebih lama daripada permintaan berikutnya.

Mengapa hal ini terjadi:

  • Inisialisasi API: Saat menganggur, lingkungan API perlu menginisialisasi selama panggilan pertama, menambahkan beberapa detik latensi
  • Pemanasan sumber data: Banyak sumber data (terutama Endpoint SQL Analytics dan gudang data) mengalami fase pemanasan ketika diakses setelah tidak aktif
  • Inisialisasi gabungan: Jika API dan sumber data sedang tidak aktif, waktu inisialisasi bergabung.

Solution:

  • Menjalankan 2-3 kueri pengujian sebelum mengukur performa
  • Untuk aplikasi produksi, terapkan titik akhir pemeriksaan kesehatan yang menjaga API tetap hangat
  • Pertimbangkan untuk menggunakan kueri terjadwal atau alat pemantauan untuk mempertahankan status aktif selama jam kerja

Ketidakselarasan regional

Masalah: Latensi tinggi secara konsisten di semua permintaan.

Mengapa hal ini terjadi: Panggilan jaringan lintas wilayah menambahkan latensi yang signifikan, terutama ketika klien, API, dan sumber data berada di wilayah Azure yang berbeda.

Solution:

  • Verifikasi aplikasi klien, kapasitas Fabric, dan sumber data Anda berada di wilayah yang sama
  • Jika akses lintas wilayah tidak dapat dihindari, terapkan strategi caching yang agresif
  • Pertimbangkan untuk menyebarkan replika API regional untuk aplikasi global

Performa sumber data

Masalah: Permintaan API lambat bahkan ketika API dipersiapkan dan region disinkronkan.

Mengapa hal ini terjadi: API untuk GraphQL bertindak sebagai antarmuka kueri atas sumber data Anda. Jika sumber data yang mendasarinya memiliki masalah performa—seperti indeks yang hilang, kueri kompleks, atau batasan sumber daya—API mewarisi batasan tersebut.

Solution:

  1. Uji secara langsung: Mengkueri sumber data secara langsung (menggunakan SQL atau alat asli lainnya) untuk menetapkan performa dasar
  2. Optimalkan sumber data:
    • Menambahkan indeks yang sesuai untuk kolom yang sering dikueri
    • Pertimbangkan penyimpanan data yang tepat untuk kasus penggunaan Anda: Panduan keputusan Fabric - pilih penyimpanan data
    • Meninjau rencana eksekusi kueri untuk peluang pengoptimalan
  3. Kapasitas ukuran yang tepat: Pastikan SKU kapasitas Fabric Anda menyediakan sumber daya komputasi yang memadai. Lihat konsep Microsoft Fabric untuk panduan tentang memilih kapasitas yang sesuai.

Desain kueri

Masalah: Beberapa kueri berjalan dengan baik sementara yang lain lambat.

Mengapa hal ini terjadi:

  • Pengambilan data yang berlebihan: Meminta lebih banyak data daripada yang diperlukan meningkatkan waktu pemrosesan.
  • Penyusunan Terdalam: Kueri dengan banyak tingkat hubungan berlapis memerlukan beberapa eksekusi penyelesai
  • Filter yang hilang: Kueri tanpa filter yang sesuai dapat mengembalikan data yang berlebihan

Solution:

  • Meminta hanya bidang yang Anda butuhkan dalam kueri GraphQL Anda
  • Batasi kedalaman hubungan berlapis jika memungkinkan
  • Gunakan filter dan penomoran halaman yang sesuai dalam kueri Anda
  • Pertimbangkan untuk memecah kueri kompleks menjadi beberapa kueri yang lebih sederhana jika sesuai

Konten terkait

  • Last updated on