Dan selamat datang kembali ke backspace Academy dalam kuliah ini.
Kami akan memperluas pengetahuan kami tentang API Gateway dan melihat cara kami dapat
meningkatkan kinerja dan keandalan API kami.
Kita akan melihat pelambatan Jadi apa yang terjadi ketika layanan API kami mendapatkan terlalu banyak permintaan yang tidak
dapat ditangani.
Dan apa yang dapat kita lakukan untuk membuat yang lebih baik akan melihat casing API dan bagaimana
kita bisa mendapatkan konten dan set case yang digunakan secara teratur sehingga kita mendapatkan respon latensi yang sangat rendah untuk permintaan kita dan juga
agar kita dapat mengurangi biaya yang terkait dengan API kita. layanan gateway.
Kami juga akan melihat rencana penggunaan yang dapat kami siapkan untuk setiap pengguna layanan kami dan
kami juga akan melihat beberapa masalah yang diketahui di
sekitar API Gateway ketika layanan API Anda menerima terlalu banyak permintaan yang tidak dapat ditangani.
Saat itulah pelambatan terjadi.
Dan setiap permintaan lebih lanjut akan menerima 4 2 9 era permintaan banyak pelambatan dan apa yang
sebenarnya dicekik didasarkan pada algoritma token bucket dan yang memiliki dua komponen.
Jadi pertama ada tingkat permintaan tetap per batas detik.
Jadi apa artinya adalah bahwa selama periode satu detik Anda hanya diperbolehkan untuk mengirim atau menerima begitu
banyak permintaan selama periode itu jika Anda melebihi jumlah permintaan selama periode kedua.
Setiap permintaan tambahan akan dicekik dan mereka akan dikirim kembali dengan empat puluh sembilan ERA.
Komponen lainnya adalah jumlah total permintaan bersamaan.
Batasi apa artinya itu pada waktu tertentu jika API Anda terkena sejumlah besar
permintaan bersamaan dan melebihi batas tertentu.
Setiap permintaan tambahan yang melebihi batas itu akan dicekik lagi dan akan menerima empat hingga sembilan pesan
kesalahan.
Kembali level akun default batas pelambatan adalah 10000 untuk kondisi mapan.
Jadi selama periode satu detik Anda dapat menerima 10.000 permintaan atau pada satu titik waktu batas Anda akan menjadi
5.000 permintaan atau permintaan bersamaan dan itu adalah batas burst Anda.
Sekarang ini dapat ditingkatkan dengan mendaftar ke AWOL jika Anda menemukan bahwa itu tidak cukup untuk Anda.
Sekarang Anda juga dapat menentukan batas pelambatan standar khusus dan yang dapat diterapkan ke tahap
tertentu atau metode API.
Sekarang batas pelambatan standar tersebut tidak dapat melebihi batas level akun.
Jadi, jika Anda memiliki 10.000 untuk kondisi mapan Anda, Anda hanya bisa naik hingga 10.000, Anda tidak bisa pergi ke sebelas ribu Anda
dapat memasukkan 8000 dan sama jika meledak
Anda dapat memasukkan ulang tahun 4000 untuk API tetapi Anda tidak dapat memasukkan enam ribu kecuali jika pembatasan
level akun Anda telah diubah dari
default, jadi mari kita lihat bagaimana cara kerjanya pada sumbu vertikal di sini.
Kami mendapat jumlah permintaan dan garis merah bertitik di sana menentukan batas burst permintaan 5000 kami dan garis
biru kami di sana menunjukkan jumlah permintaan luar biasa yang telah diterima oleh API kami.
Jadi awalnya kami mendapatkan 5000 permintaan masuk.
Apa pun di atas 5.000 akan dibatasi.
Dan pada saat itu di sana kita meledak terbatas.
Kami hanya dapat menerima 5000 dan kemudian dalam jangka waktu tertentu di sana jumlah permintaan akan
berkurang karena API kami memenuhi permintaan tersebut.
Dan di sini kita melihatnya pada titik nol koma lima detik kita telah melewati semua permintaan kita dan
kemudian kita menerima ledakan permintaan lagi.
Dan lagi kita bisa mencapai 5000 tetapi kita tidak bisa melampaui itu sehingga kita hanya dapat menerima 5000.
Dan kemudian itu turun lagi kita bisa melewatinya.
Jadi itu meledak terbatas tetapi tidak terbatas pada kondisi mapan.
Dan itu karena kami telah menerima 5.000 di sini dan kemudian kami menerima 5.000 permintaan lainnya dalam satu waktu tertentu
di sana.
Jadi jumlah total permintaan yang kami terima selama satu periode kedua adalah 10.000 dan
itu di bawah tingkat kondisi stabil kami yaitu 10.000 permintaan per detik.
Dan kami belum melampaui batas burst kami 5.000.
Mereka
baik-baik saja jadi mari kita lihat contoh lain di sini jadi pada satu detik di sini kita punya ledakan permintaan lain yang datang
dari permintaan bersamaan sehingga kita hanya bisa menerima 5000 dari mereka.
Dan apa pun di atas 5.000 akan meledak terbatas.
Sekarang selama periode waktu kami mendapatkan tiga atau API melewati permintaan tersebut dan kami
menerima banyak lagi permintaan yang datang bersamaan.
Sekarang kita hanya dapat mencapai lima ribu di sini sehingga kita hanya dapat menerima dua setengah ribu
lagi untuk membawa kita ke sini.
Jadi kita sudah menerima 5.000 plus dua setengah ribu yang berarti tujuh setengah ribu.
Sekarang kita akan melewati 5000 itu selama periode waktu di sini dan kemudian pada
titik ini di sini kita menerima banyak permintaan lagi.
Sekarang kita tidak akan meledak terbatas di sini kita akan menjadi tingkat
steady state terbatas karena selama periode satu detik kita tidak dapat melebihi 10.000 permintaan
Jadi jumlah rata-rata permintaan selama periode kedua tidak dapat melebihi 10.000.
Jadi kita sudah sampai di sini, kita menerima 5.000, kemudian kita menerima dua setengah ribu
lagi, yaitu tujuh setengah ribu yang hanya tersisa dua setengah ribu.
Jadi kami hanya dapat menerima dua dan ribuan permintaan kami di atas
bahwa itu akan menjadi tingkat kondisi tetap terbatas untuk mengurangi kemungkinan pelambatan yang terjadi pada layanan API Anda.
Anda dapat menerapkan casing API.
Apa yang dilakukan adalah hal itu populer Anda menyeberang ke titik akhir Anda dan yang akan
mengurangi jumlah panggilan ke titik akhir karena akan mengirimkan permintaan dari kasus API.
Itu akan mengurangi latensi tanggapan tersebut dan itu jelas akan mengurangi biaya.
Anda akan dikenai biaya per jam untuk menggunakan kasing API meskipun ini bukan pada tingkat gratis AWB
tetapi akan mengurangi jumlah panggilan ke titik akhir Anda yang sudah ada dalam kasing API Anda waktu default untuk hidup.
Untuk kasus Anda yang 300 detik atau lima menit dan maksimum adalah enam ratus detik atau satu jam
rencana penggunaan dapat memungkinkan API yang digunakan untuk digunakan sebagai produk yang menawarkan cara itu menggunakan
kunci API yang mengidentifikasi klien individu terhubung ke API dan itu akan memiliki batasan pelambatan dan
Kuroda.
Itu akan diberlakukan pada klien itu dan khusus untuk Clyde atau kelompok klien yang
akan dihasilkan di konsol atau diimpor sebagai file dalam format file kunci API permintaan akan bekerja sebelum kunci API kapan
pun dan rencana penggunaan adalah diberlakukan sehingga Anda tidak akan dapat mengakses API kecuali jika Anda menggunakan kunci
API ketika rencana penggunaan ada fitur yang baik dari ini adalah bahwa tidak hanya dapat
digunakan sebagai produk yang menawarkan itu juga dapat dijual sebagai layanan di AWB sebagai pasar ada daftar signifikan masalah yang
diketahui dengan layanan gateway Adobe US API salah satunya adalah bahwa engine X mungkin tidak
sepenuhnya mendukung otentikasi klien SSL.
Saya pikir itu yang penting.
Tidak semua spesifikasi angkuh diimplementasikan walaupun itu bukan masalah besar karena cukup baik semua yang Anda
butuhkan telah diimplementasikan tetapi tentu saja ada daftar masalah yang signifikan dan saya
tidak akan mendaftar semuanya di sini karena daftar itu berubah cukup secara teratur karena Adobe
kami meningkatkan layanan ini tetapi untuk informasi terbaru tentang itu, silakan kunjungi masalah yang diketahui di panduan
pengembang US API Gateway adobe.
Sehingga membawa kita pada akhir kuliah ini.
Saya harap Anda menikmatinya dan sampai jumpa di yang berikutnya.