Menangani masalah pembatasan (kesalahan 429 - "Terlalu banyak permintaan") di Azure Logic Apps
Berlaku untuk: Azure Logic Apps (Konsumsi + Standar)
Jika alur kerja aplikasi logika Anda mengalami pembatasan, yang terjadi ketika jumlah permintaan melebihi tingkat di mana tujuan dapat menangani selama jumlah waktu tertentu, Anda mendapatkan kesalahan "HTTP 429 Terlalu banyak permintaan". Pembatasan dapat membuat masalah seperti pemrosesan data yang tertunda, kecepatan performa yang menurun, dan kesalahan seperti melebihi kebijakan percobaan kembali yang ditentukan.
Misalnya, tindakan SQL Server berikut dalam alur kerja Konsumsi menunjukkan kesalahan 429, yang melaporkan masalah pembatasan:
Bagian berikut ini menjelaskan tingkat umum di mana alur kerja Anda mungkin mengalami pembatasan:
Pembatasan Sumber Daya untuk Aplikasi Logika
Azure Logic Apps memiliki batas throughput sendiri. Jika sumber daya aplikasi logika Anda melebihi batas ini, sumber daya aplikasi logika Anda akan dibatasi, bukan hanya instans alur kerja tertentu atau dijalankan.
Untuk menemukan peristiwa pembatasan di tingkat ini, ikuti langkah-langkah berikut:
Di portal Microsoft Azure, buka sumber daya aplikasi logika Anda.
Pada menu sumber daya aplikasi logika, di bawah Pemantauan, pilih Metrik.
Di bawah Judul Bagan, pilih Tambahkan metrik, yang menambahkan bilah metrik lain ke bagan.
Di bilah metrik pertama, dari daftar Metrik , pilih Peristiwa Pembatasan Tindakan. Dari daftar Agregasi , pilih Hitung.
Di bilah metrik kedua, dari daftar Metrik , pilih Peristiwa Yang Dibatasi Pemicu. Dari daftar Agregasi , pilih Hitung.
Bagan sekarang menunjukkan peristiwa yang dibatasi untuk tindakan dan pemicu dalam alur kerja aplikasi logika Anda. Untuk informasi selengkapnya, lihat Menampilkan metrik untuk kesehatan dan performa alur kerja di Azure Logic Apps.
Untuk menangani pembatasan pada tingkat ini, Anda memiliki opsi berikut:
Batasi jumlah instans alur kerja yang dapat berjalan secara bersamaan.
Secara default, jika kondisi pemicu alur kerja Anda terpenuhi lebih dari sekali pada saat yang sama, maka beberapa instans pemicu tersebut diaktifkan dan berjalan secara bersamaan atau paralel. Setiap instans pemicu diaktifkan sebelum instans alur kerja sebelumnya selesai berjalan.
Meskipun jumlah default instance pemicu yang dapat dijalankan secara bersamaan tidak terbatas, Anda dapat membatasi jumlah ini dengan mengaktifkan pengaturan konkurensi pemicu, dan jika perlu, pilih batas selain nilai default.
Aktifkan mode throughput tinggi.
Alur kerja Konsumsi memiliki batas default untuk jumlah tindakan yang dapat berjalan selama interval bergulir 5 menit. Untuk menaikkan batas ini ke jumlah maksimum tindakan, aktifkan mode throughput tinggi pada sumber daya aplikasi logika Anda.
Alur kerja Standar tidak memiliki batasan jumlah tindakan yang dapat berjalan selama interval apa pun.
Nonaktifkan debatching array atau perilaku "Split On" dalam pemicu.
Jika pemicu mengembalikan array untuk tindakan alur kerja yang tersisa untuk diproses, pengaturan Split On pemicu membagi item array dan memulai instans alur kerja untuk setiap item array. Perilaku ini secara efektif memicu beberapa eksekusi bersamaan hingga batas Split On.
Untuk mengontrol pembatasan, nonaktifkan perilaku Split On pemicu dan minta alur kerja Anda memproses seluruh array dengan satu panggilan, daripada menangani satu item per panggilan.
Refaktor tindakan menjadi beberapa alur kerja yang lebih kecil.
Seperti disebutkan sebelumnya, alur kerja aplikasi logika Konsumsi terbatas pada jumlah tindakan default yang dapat berjalan selama periode 5 menit. Meskipun Anda dapat meningkatkan batas ini dengan mengaktifkan mode throughput tinggi, Anda mungkin juga mempertimbangkan apakah Anda ingin memecah tindakan alur kerja Menjadi alur kerja yang lebih kecil sehingga jumlah tindakan yang berjalan di setiap alur kerja tetap di bawah batas. Dengan demikian, Anda mengurangi beban pada satu alur kerja dan mendistribusikan beban di beberapa alur kerja. Solusi ini bekerja lebih optimal untuk tindakan yang menangani himpunan data besar atau memutar begitu banyak tindakan yang berjalan bersamaan, iterasi pengulangan, atau tindakan di dalam setiap perulangan loop sehingga mereka melebihi batas eksekusi tindakan.
Misalnya, alur kerja Konsumsi berikut melakukan semua pekerjaan untuk mendapatkan tabel dari database SQL Server dan mendapatkan baris dari setiap tabel. Perulangan Untuk setiap melakukan iterasi secara bersamaan melalui setiap tabel sehingga tindakan Dapatkan baris menghasilkan baris untuk setiap tabel. Berdasarkan jumlah data dalam tabel tersebut, tindakan ini mungkin melebihi batas eksekusi tindakan.
Setelah refaktor, alur kerja asli dibagi menjadi alur kerja induk dan alur kerja anak.
Alur kerja induk berikut mendapatkan tabel dari SQL Server lalu memanggil alur kerja anak untuk setiap tabel untuk mendapatkan baris:
Alur kerja anak berikut dipanggil oleh alur kerja induk untuk mendapatkan baris untuk setiap tabel:
Pembatasan konektor
Setiap konektor memiliki batas pembatasannya sendiri, yang dapat Anda temukan di setiap halaman referensi teknis konektor. Misalnya, konektor Azure Service Bus memiliki batas pembatasan yang memungkinkan hingga 6.000 panggilan per menit, sementara SQL Server Connector memiliki batas pembatasan yang bervariasi berdasarkan jenis operasi.
Beberapa pemicu dan tindakan, seperti HTTP, memiliki "kebijakan percobaan kembali" yang dapat Anda sesuaikan berdasarkan batas kebijakan percobaan kembali untuk mengimplementasikan penanganan pengecualian. Kebijakan ini menentukan apakah dan seberapa sering pemicu atau tindakan mencoba kembali permintaan ketika permintaan asli gagal atau kehabisan waktu serta menghasilkan respons 408, 429, atau 5xx. Jadi, saat pembatasan dimulai dan menampilkan kesalahan 429, Logic Apps akan mengikuti kebijakan percobaan kembali jika didukung.
Untuk mempelajari apakah pemicu atau tindakan mendukung kebijakan percobaan kembali, periksa pengaturan tindakan atau pemicu. Untuk melihat pemicu atau upaya coba lagi tindakan, buka riwayat eksekusi aplikasi logika Anda, pilih eksekusi yang ingin Anda tinjau, dan perluas pemicu atau tindakan tersebut untuk melihat detail tentang input, output, dan percobaan ulang apa pun.
Contoh alur kerja Konsumsi berikut menunjukkan tempat Anda dapat menemukan informasi ini untuk tindakan HTTP:
Meskipun riwayat percobaan kembali memberikan informasi kesalahan, Anda mungkin mengalami masalah dalam membedakan antara pembatasan konektor dan pembatasan tujuan. Dalam hal ini, Anda mungkin harus meninjau detail respons atau melakukan beberapa penghitungan interval pembatasan untuk mengidentifikasi sumber.
Untuk alur kerja aplikasi logika Konsumsi di Azure Logic Apps multipenyewa, pembatasan terjadi pada tingkat koneksi .
Untuk menangani pembatasan pada tingkat ini, Anda memiliki opsi berikut:
Siapkan beberapa koneksi untuk satu tindakan sehingga alur kerja dapat mempartisi data untuk diproses.
Pertimbangkan apakah Anda dapat mendistribusikan beban kerja dengan membagi permintaan tindakan di beberapa koneksi ke tujuan yang sama menggunakan kredensial yang sama.
Misalnya, alur kerja Anda mendapatkan tabel dari database SQL Server lalu mendapatkan baris dari setiap tabel. Berdasarkan jumlah baris yang harus Anda proses, Anda dapat menggunakan beberapa koneksi dan perulangan Untuk setiap untuk membagi jumlah total baris menjadi set yang lebih kecil untuk diproses. Skenario ini menggunakan dua perulangan Untuk setiap untuk membagi jumlah total baris menjadi dua. Perulangan Untuk setiap yang pertama menggunakan ekspresi yang mendapatkan bagian pertama. Perulangan Untuk setiap lainnya menggunakan ekspresi berbeda yang mendapatkan bagian kedua, misalnya:
Ekspresi 1: Fungsi
take()mendapatkan bagian depan koleksi. Untuk informasi selengkapnya, lihat fungsitake().@take(collection-or-array-name, div(length(collection-or-array-name), 2))Ekspresi 2: Fungsi
skip()menghapus bagian depan koleksi dan menampilkan semua item lainnya. Untuk informasi selengkapnya, lihat fungsiskip().@skip(collection-or-array-name, div(length(collection-or-array-name), 2))Contoh alur kerja Konsumsi berikut ini memperlihatkan bagaimana Anda bisa menggunakan ekspresi ini:
Siapkan koneksi yang berbeda untuk setiap tindakan.
Pertimbangkan apakah Anda dapat mendistribusikan beban kerja dengan menyebarkan permintaan setiap tindakan melalui koneksi mereka sendiri, bahkan ketika tindakan terhubung ke layanan atau sistem yang sama dan menggunakan kredensial yang sama.
Misalnya, alur kerja Anda mendapatkan tabel dari database SQL Server dan mendapatkan setiap baris di setiap tabel. Anda bisa menggunakan koneksi terpisah sehingga proses mendapatkan tabel menggunakan satu koneksi, sementara proses mendapatkan setiap baris menggunakan koneksi lain.
Contoh berikut menunjukkan alur kerja Konsumsi yang membuat dan menggunakan koneksi yang berbeda untuk setiap tindakan:
Ubah konkurensi atau paralelisme pada perulangan "Untuk setiap".
Secara default, iterasi perulangan "Untuk setiap" berjalan pada waktu yang sama hingga batas konkurensi. Jika Anda memiliki koneksi yang dibatasi di dalam perulangan "Untuk setiap", Anda dapat mengurangi jumlah iterasi perulangan yang berjalan secara paralel. Untuk informasi selengkapnya, lihat dokumentasi berikut:
Pembatasan sistem atau layanan tujuan
Meskipun konektor memiliki batas pembatasannya sendiri, sistem atau layanan tujuan yang dipanggil konektor mungkin juga memiliki batas pembatasan. Misalnya, beberapa API di Microsoft Exchange Server memiliki batas pembatasan lebih ketat daripada konektor Office 365 Outlook.
Secara default, instans alur kerja aplikasi logika dan perulangan atau cabang apa pun di dalam instans tersebut, berjalan secara paralel. Perilaku ini berarti bahwa beberapa instans dapat memanggil titik akhir yang sama secara bersamaan. Setiap instans tidak tahu tentang keberadaan yang lain, sehingga upaya untuk mencoba kembali tindakan yang gagal dapat membuat kondisi pacu di mana beberapa panggilan mencoba untuk berjalan pada saat yang sama, tetapi untuk berhasil, panggilan tersebut harus tersambung di layanan atau sistem tujuan sebelum pembatasan mulai terjadi.
Misalnya, anggap Anda memiliki array yang berisi 100 item. Anda menggunakan perulangan "Untuk setiap" untuk melakukan iterasi melalui array dan mengaktifkan kontrol konkurensi perulangan sehingga Anda dapat membatasi jumlah perulangan paralel hingga 20 atau batas default saat ini. Di dalam perulangan tersebut, tindakan akan menyisipkan item dari array ke dalam database SQL Server, yang hanya mengizinkan 15 panggilan per detik. Skenario ini menghasilkan masalah pembatasan karena backlog percobaan ulang dibangun dan tidak pernah berjalan.
Tabel berikut ini menjelaskan garis waktu untuk apa yang terjadi dalam perulangan saat interval coba lagi tindakan adalah 1 detik:
| Titik waktu | Jumlah tindakan yang berjalan | Jumlah tindakan yang gagal | Jumlah percobaan ulang yang menunggu |
|---|---|---|---|
| T + 0 detik | 20 sisipan | 5 gagal karena batas SQL | 5 percobaan ulang |
| T + 0,5 detik | 15 sisipan, karena 5 percobaan ulang sebelumnya menunggu | 15 semuanya gagal, karena batas SQL sebelumnya masih berlaku selama 0,5 detik lagi | 20 percobaan ulang (5 sebelumnya + 15 baru) |
| T + 1 detik | 20 sisipan | 5 gagal plus 20 percobaan ulang sebelumnya, karena batas SQL | 25 percobaan ulang (20 sebelumnya + 5 baru) |
Untuk menangani pembatasan pada tingkat ini, Anda memiliki opsi berikut:
Buat alur kerja individual sehingga masing-masing menangani satu operasi.
Melanjutkan dengan contoh skenario SQL Server di bagian ini, Anda dapat membuat alur kerja yang memasukkan item array ke dalam antrean, seperti antrean Azure Bus Layanan. Anda kemudian membuat alur kerja lain yang hanya melakukan operasi sisipkan untuk setiap item dalam antrean tersebut. Dengan begitu, hanya satu instans alur kerja yang berjalan pada waktu tertentu, yang menyelesaikan operasi penyisipan dan melanjutkan ke item berikutnya dalam antrean, atau instans mendapatkan 429 kesalahan tetapi tidak mencoba percobaan ulang yang tidak produktif.
Buat alur kerja induk yang memanggil alur kerja turunan atau berlapis untuk setiap tindakan. Jika induk perlu memanggil alur kerja turunan yang berbeda berdasarkan hasil induk, Anda dapat menggunakan tindakan kondisi atau beralih tindakan yang menentukan alur kerja turunan mana yang akan dipanggil. Pola ini dapat membantu Anda mengurangi jumlah panggilan atau operasi.
Misalnya, Anda memiliki dua alur kerja, masing-masing dengan pemicu polling yang memeriksa akun email Anda setiap menit untuk subjek tertentu, seperti "Berhasil" atau "Kegagalan". Penyiapan ini menghasilkan 120 panggilan per jam. Sebaliknya, jika Anda membuat alur kerja induk tunggal yang melakukan polling setiap menit tetapi memanggil alur kerja anak yang berjalan berdasarkan apakah subjeknya adalah "Berhasil" atau "Kegagalan", Anda memotong jumlah pemeriksaan polling menjadi setengahnya, atau 60 dalam hal ini.
Siapkan pemrosesan batch. (Hanya alur kerja konsumsi)
Jika layanan destinasi mendukung operasi batch, Anda dapat mengatasi pembatasan dengan memproses item dalam grup atau batch, bukan secara individual. Untuk menerapkan solusi pemrosesan batch, Anda membuat alur kerja aplikasi logika "penerima batch" dan alur kerja aplikasi logika "pengirim batch". Pengirim batch mengumpulkan pesan atau item hingga kriteria yang Anda tentukan terpenuhi, lalu mengirim pesan atau item tersebut dalam satu grup. Penerima batch menerima grup tersebut dan memproses pesan atau itemnya. Untuk informasi selengkapnya, lihat Pesan proses batch dalam grup.
Gunakan versi webhook untuk pemicu dan tindakan, bukan versi polling.
Mengapa? Pemicu polling terus memeriksa sistem atau layanan tujuan pada interval tertentu. Interval yang sangat sering, seperti setiap detik, dapat menciptakan masalah pembatasan. Namun, pemicu atau tindakan webhook, seperti Webhook HTTP, hanya membuat satu panggilan ke sistem atau layanan tujuan, yang terjadi pada waktu berlangganan dan meminta tujuan agar memberi tahu pemicu atau tindakan hanya ketika peristiwa terjadi. Dengan begitu, pemicu atau tindakan tidak harus terus-menerus memeriksa tujuan.
Jadi, jika sistem atau layanan tujuan mendukung webhook atau menyediakan konektor yang memiliki versi webhook, opsi ini lebih baik daripada menggunakan versi polling. Untuk mengidentifikasi pemicu dan tindakan webhook, konfirmasi bahwa keduanya memiliki jenis
ApiConnectionWebhookatau tidak mengharuskan Anda menentukan pengulangan. Untuk informasi selengkapnya, lihat pemicu APIConnectionWebhook dan tindakan APIConnectionWebhook.