Bagikan melalui

Tarif dan batas penggunaan

  • Artikel

Azure DevOps

Layanan Azure DevOps menggunakan multi-penyewaan untuk mengurangi biaya dan meningkatkan performa. Desain ini membuat pengguna rentan terhadap masalah performa dan bahkan pemadaman ketika pengguna lain dari sumber daya bersama mereka mengalami lonjakan konsumsi mereka. Jadi, Azure DevOps membatasi sumber daya yang dapat dikonsumsi individu, dan jumlah permintaan yang dapat mereka buat untuk perintah tertentu. Ketika batas ini terlampaui, permintaan di masa mendatang mungkin tertunda atau diblokir.

Untuk informasi selengkapnya, lihat Batas Git dan Praktik terbaik untuk menghindari mencapai batas laju.

Batas konsumsi global

Azure DevOps saat ini memiliki batas konsumsi global, yang menunda permintaan dari pengguna individu di luar ambang saat sumber daya bersama dalam bahaya kewalahan. Batas ini difokuskan secara eksklusif untuk menghindari pemadaman ketika sumber daya bersama hampir kewalahan. Pengguna individual biasanya hanya mendapatkan permintaan yang tertunda ketika salah satu insiden berikut terjadi:

  • Salah satu sumber daya bersama mereka berisiko kewalahan
  • Penggunaan pribadi mereka melebihi 200 kali konsumsi pengguna umum dalam jendela lima menit (geser)

Jumlah penundaan tergantung pada tingkat konsumsi pengguna yang berkelanjutan. Penundaan berkisar dari beberapa milidetik per permintaan hingga 30 detik. Setelah konsumsi masuk ke nol atau sumber daya tidak lagi kewalahan, penundaan berhenti dalam waktu lima menit. Jika konsumsi tetap tinggi, penundaan mungkin berlanjut tanpa batas waktu untuk melindungi sumber daya.

Ketika permintaan pengguna tertunda oleh jumlah yang signifikan, pengguna tersebut menerima email dan banner peringatan di web. Untuk akun layanan build dan lainnya tanpa alamat email, anggota grup Administrator Koleksi Proyek mendapatkan email. Untuk mengetahui informasi selengkapnya, lihat Pemantauan penggunaan.

Ketika permintaan pengguna individu diblokir, respons dengan kode HTTP 429 (terlalu banyak permintaan) diterima, dengan pesan yang mirip dengan pesan berikut:

TF400733: The request has been canceled: Request was blocked due to exceeding usage of resource <resource name> in namespace <namespace ID>.

Unit throughput Azure DevOps (TSTUs)

Pengguna Azure DevOps menggunakan banyak sumber daya bersama, dan konsumsi bergantung pada faktor-faktor berikut:

  • Mengunggah sejumlah besar file ke kontrol versi membuat sejumlah besar beban pada database dan akun penyimpanan
  • Kueri pelacakan item kerja yang kompleks membuat beban database berdasarkan jumlah item kerja yang mereka cari
  • Membangun beban drive dengan mengunduh file dari kontrol versi, menghasilkan output log
  • Semua operasi mengonsumsi CPU dan memori di berbagai bagian layanan

Untuk mengakomodasi, konsumsi sumber daya Azure DevOps dinyatakan dalam unit abstrak yang disebut unit throughput Azure DevOps, atau TSTUs. TSTUs akhirnya menggabungkan perpaduan item berikut:

  • DTU Azure SQL Database sebagai ukuran konsumsi database
  • Tingkat aplikasi dan CPU agen pekerjaan, memori, dan I/O sebagai ukuran konsumsi komputasi
  • Bandwidth Azure Storage sebagai ukuran konsumsi penyimpanan

Untuk saat ini, TSTUs terutama difokuskan pada DTU Azure SQL Database, karena Azure SQL Database adalah sumber daya bersama yang paling umum dilimpahi oleh konsumsi yang berlebihan. Satu TSTU adalah beban rata-rata yang kami harapkan untuk dihasilkan oleh satu pengguna normal Azure DevOps per lima menit. Pengguna normal juga menghasilkan lonjakan beban. Lonjakan ini biasanya 10 atau lebih sedikit TSTUs per lima menit. Lebih jarang, lonjakan setinggi 100 TSTUs.

Batas konsumsi global adalah 200 TSTUs dalam jendela lima menit geser.

Sebaiknya Anda setidaknya merespons Retry-After header. Jika Anda mendeteksi Retry-After header dalam respons apa pun, tunggu hingga beberapa waktu berlalu sebelum Anda mengirim permintaan lain. Melakukannya membantu aplikasi klien Anda mengalami lebih sedikit penundaan yang diberlakukan. Perlu diingat bahwa responsnya adalah 200, sehingga Anda tidak perlu menerapkan logika coba lagi ke permintaan.

Jika memungkinkan, kami sarankan Anda memantau X-RateLimit-Remaining dan X-RateLimit-Limit header lebih lanjut. Melakukannya memungkinkan Anda untuk mempertanyakan seberapa cepat Anda mendekati ambang penundaan. Klien Anda dapat dengan cerdas bereaksi dan menyebarkan permintaannya dari waktu ke waktu.

Catatan

Identitas yang digunakan oleh alat dan aplikasi untuk berintegrasi dengan Azure DevOps mungkin memerlukan tingkat dan batas penggunaan yang lebih tinggi di luar batas konsumsi yang diizinkan dari waktu ke waktu. Anda bisa mendapatkan tarif dan batas penggunaan tambahan dengan menetapkan tingkat akses Paket Dasar + Pengujian ke identitas yang diinginkan yang digunakan oleh aplikasi Anda. Setelah kebutuhan akan batas tarif yang lebih tinggi terpenuhi, Anda dapat kembali ke tingkat akses yang biasa dimiliki identitas. Anda dikenakan biaya tingkat akses Paket Dasar + Pengujian hanya untuk waktu yang ditetapkan ke identitas.

Identitas yang sudah ditetapkan langganan Visual Studio Enterprise tidak dapat ditetapkan tingkat akses Paket Dasar + Pengujian hingga dihapus.

Pipelines

Pembatasan tarif mirip untuk Azure Pipelines. Setiap alur diperlakukan sebagai entitas individual dengan konsumsi sumber dayanya sendiri yang dilacak. Meskipun dihost sendiri, agen build menghasilkan beban dalam bentuk kloning dan mengirim log.

Kami menerapkan batas 200 TSTU untuk masing-masing alur dalam jangka waktu bergeser selama 5 menit. Batas ini sama dengan batas konsumsi global untuk pengguna. Jika alur tertunda atau diblokir oleh pembatasan tarif, pesan muncul di log terlampir.

Pengalaman klien API

Saat permintaan ditunda atau diblokir, Azure DevOps mengembalikan header respons untuk membantu klien API bereaksi. Meskipun tidak sepenuhnya standar, header ini secara luas sejalan dengan layanan populer lainnya.

Tabel berikut mencantumkan header yang tersedia dan apa artinya. Kecuali untuk X-RateLimit-Delay, semua header ini dikirim sebelum permintaan mulai tertunda. Desain ini memberi klien kesempatan untuk secara proaktif memperlambat laju permintaan mereka.

Nama header

Keterangan

Retry-After

Header yang ditentukan RFC 6585 dikirim untuk memberi tahu Anda berapa lama menunggu sebelum Anda mengirim permintaan berikutnya untuk berada di bawah ambang deteksi. Unit: detik.

X-RateLimit-Resource

Header kustom yang menunjukkan layanan dan jenis ambang batas yang tercapai. Jenis ambang batas dan nama layanan mungkin bervariasi dari waktu ke waktu dan tanpa peringatan. Sebaiknya tampilkan string ini kepada manusia, tetapi tidak mengandalkannya untuk komputasi.

X-RateLimit-Delay

Berapa lama permintaan tertunda. Unit: detik dengan hingga tiga tempat desimal (milidetik).

X-RateLimit-Limit

Jumlah total TSU yang diizinkan sebelum penundaan diberlakukan.

X-RateLimit-Remaining

Jumlah TSTUs yang tersisa sebelum ditunda. Jika permintaan sudah ditunda atau diblokir, itu adalah 0.

X-RateLimit-Reset

Waktu di mana, jika semua konsumsi sumber daya segera berhenti, penggunaan terlacak akan kembali ke 0 TSTUs. Dinyatakan dalam waktu epoch Unix.

Pelacakan kerja, proses, & batas proyek

Azure DevOps memberlakukan batasan untuk jumlah proyek yang dapat Anda miliki di organisasi dan jumlah tim yang dapat Anda miliki dalam setiap proyek. Perhatikan juga batasan untuk item kerja, kueri, backlog, papan, dasbor, dan banyak lagi. Untuk informasi selengkapnya, lihat Pelacakan kerja, proses, dan batas proyek.

Wiki

Selain batas repositori yang biasa, wiki yang ditentukan untuk proyek dibatasi hingga 25 MB per satu file.

Koneksi layanan

Tidak ada batas per proyek yang ditempatkan pada pembuatan koneksi layanan. Namun, mungkin ada batasan, yang diberlakukan melalui ID Microsoft Entra. Untuk informasi tambahan, tinjau artikel berikut ini: