Aracılığıyla paylaş

Oran ve kullanım sınırları

Azure DevOps Hizmetleri

Azure DevOps Services, maliyetleri azaltmak ve performansı geliştirmek için çok kiracılı hizmet kullanır. Bu tasarım, diğer paylaşılan kaynak kullanıcılarının tüketiminde ani artışlar olduğunda performans sorunlarına veya kesintilere neden olabilir. Azure DevOps, bunu önlemeye yardımcı olmak için her kullanıcının kullanabileceği kaynakları ve belirli komutlara yapabilecekleri istek sayısını sınırlar. Bu sınırları aşarsanız, gelecekteki istekler gecikebilir veya engellenebilir.

Git sınırları ve Hız sınırlarına çarpmamak için en iyi yöntemler bölümünden daha fazla bilgi edinin.

Genel tüketim sınırı

Azure DevOps, paylaşılan kaynakların aşırı yüklenme riski altında olduğunda tek tek kullanıcılardan gelen istekleri geciktiren genel bir tüketim sınırına sahiptir. Bu sınır, paylaşılan kaynaklar aşırı yüklenmeye yaklaştığında kesintileri önlemeye yardımcı olur. Bireysel kullanıcılar genellikle gecikmeli isteklerle yalnızca aşağıdaki olaylardan biri gerçekleştiğinde karşılaşır:

  • Paylaşılan kaynaklarından biri bunalma riski altındadır.
  • Kişisel kullanım miktarı, hareketli beş dakikalık bir zaman dilimi içinde tipik bir kullanıcının tüketiminin 200 katını aşıyor.

Gecikme, kullanıcının sürekli tüketim düzeyine bağlıdır. Gecikmeler istek başına birkaç milisaniyeden 30 saniyeye kadar değişir. Tüketim sıfıra düştüğünde veya kaynak aşırı yüklenmediğinde, gecikmeler beş dakika içinde durur. Tüketim yüksek kalırsa, kaynağı korumak için gecikmeler süresiz olarak devam edebilir.

Bir kullanıcı isteği önemli miktarda geciktirildiğinde, kullanıcı web'de bir e-posta ve bir uyarı başlığı alır. Derleme hizmeti hesabı ve e-posta adresi olmayan diğer kullanıcılar için, Proje Koleksiyonu Yöneticileri grubunun üyeleri e-postayı alır. Daha fazla bilgi için bkz. Kullanım izleme.

Tek bir kullanıcının istekleri engellendiğinde, kullanıcı HTTP kodu 429 (çok fazla istek) ve aşağıdakine benzer bir ileti içeren yanıtlar alır:

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

Azure DevOps aktarım hızı birimleri

Azure DevOps kullanıcıları birçok paylaşılan kaynak kullanır ve tüketim düzeyi aşağıdaki faktörlere bağlıdır:

  • Sürüm denetimine çok sayıda dosya yükleyerek veritabanlarına ve depolama hesaplarına yük bindirebilirsiniz.
  • Karmaşık iş öğesi sorgularının çalıştırılması, aranmakta olan iş öğelerinin sayısına göre veritabanı yükünü artırır.
  • Sürüm denetiminden dosya indirip günlük çıktısı üreten derlemelerin çalıştırılması.
  • Hizmetin farklı bölümlerinde CPU ve bellek kullanan genel işlemler.

Azure DevOps, bu etkinliği ölçmek için Azure DevOps aktarım hızı birimlerinde (TSTU) kaynak tüketimini ifade eder. TSTU, aşağıdakileri içeren farklı kaynakların bir karışımını temsil eden soyut bir yük birimidir:

  • Veritabanı kullanımı; öncelikle Azure SQL Veritabanı DTU'ları aracılığıyla ölçülür.
  • Uygulama katmanlarından ve iş aracılarından CPU, bellek ve G/Ç kullanımını hesaplayın.
  • Depolama kullanımı— Azure Depolama bant genişliği.

Uyarı

TSTU'lar kasıtlı olarak soyut olur. Dağıtılmış bir altyapı içindeki işlem, depolama ve veritabanı katmanlarında kaynak tüketimini toplar. Destekleyen metrikler (CPU, bellek, G/Ç, DTU) doğrudan kullanıma sunulmaz ve tek başına anlamlı değildir. TSTU'lar, tek tek kaynak bileşenlerinin tüm karmaşıklığını ortaya çıkarmadan kullanımı yönetmeyi ve izlemeyi kolaylaştırarak yükü temsil etmek için birleşik bir yol sağlar. Formül içeren bir eylem için TSTTU'lardaki kullanımı hesaplayamazsınız, ancak kullanım izleme sayfasında bir işlemin kaç TSTU tükettiğine bakabilirsiniz. İş öğesi sorguları gibi bazı işlemler, kuruluşunuz büyüdükçe ve değiştikçe tüketimde farklılık gösterir, bu nedenle doğru şekilde devam etmek için düzenli aralıklarla karşılaştırma yapmanız gerekebilir.

Şu anda veritabanları aşırı tüketimden etkilenme olasılığı en yüksek olan paylaşılan kaynak olduğundan, TSTU'lar öncelikli olarak Azure SQL Veritabanı DTU'larına odaklanır.

  • Bir TSTU, tipik bir Azure DevOps kullanıcısı tarafından beş dakika içinde oluşturulan ortalama yükü temsil eder.
  • Normal kullanıcı etkinliği beş dakikada 10 TSTU veya daha az ani artışlar oluşturabilir.
  • Daha büyük ancak daha az sıklıkta ani artışlar 100 TSTU'ya kadar ulaşabilir.
  • Genel sınır, kayan beş dakikalık bir süre içinde 200 TSTU'dur.

En iyi yöntemler

  • Retry-After üst bilgisini önemseyin: Yanıt olarak alırsanız, başka bir istek göndermeden önce belirtilen süreyi bekleyin. Yanıt hala HTTP 200 döndürür, bu nedenle yeniden deneme mantığı gerekmez.
  • X-RateLimit üst bilgilerini izleyin: Varsa, eşiğe ne kadar hızlı yaklaştığınızı anlayabilmek için X-RateLimit-Remaining ve X-RateLimit-Limit'yi izleyin. Bu, istemcinizin istek artışlarını düzeltmenize ve zorunlu gecikmeleri önlemenize olanak tanır.

Uyarı

Azure DevOps ile tümleştirmek için araçlar ve uygulamalar tarafından kullanılan kimlikler, bazen izin verilen tüketim sınırının ötesinde daha yüksek hız ve kullanım sınırlarına ihtiyaç duyabilir. Temel + Test Planları erişim düzeyini uygulamanızın kullandığı kimliklere atayarak bu sınırları artırın. Daha yüksek hız sınırlarına ihtiyacınız kalmadıktan sonra önceki erişim düzeyine geri dönebilirsiniz. Temel + Test Planları erişim düzeyi için yalnızca kimliğe atanan süre boyunca ücretlendirilirsiniz. Visual Studio Enterprise aboneliğine zaten atanmış kimliklere, siz aboneliği kaldırana kadar Temel + Test Planları erişim düzeyi atanamaz.

Boru Hatları

Hız sınırlama, Azure Pipelines için aynı şekilde çalışır. Her işlem hattı tek bir varlıktır ve kaynak tüketimi ayrı olarak izlenir. Derleme ajanları kendi kendine barındırılıyor olsa bile, günlükleri kopyalayıp göndererek yük oluşturur.

Kaydırmalı 5 dakikalık bir pencerede her işlem hattı için 200 TSTU sınırı bulunur. Bu sınır, kullanıcılar için genel tüketim sınırıyla eşleşir. Eğer oran sınırlaması bir gecikmeye veya işlem hattının engellenmesine neden oluyorsa, ekli günlüklerde bir ileti görürsünüz.

API istemci deneyimi

İstekler geciktirildiğinde veya engellendiğinde Azure DevOps, API istemcilerinin tepki vermesine yardımcı olmak için yanıt üst bilgilerini döndürür. Tam olarak standartlaştırılmasa da, bu başlıklar diğer popüler hizmetlerle genel olarak uyumlu.

Aşağıdaki tabloda kullanılabilir üst bilgiler ve bunların anlamı listeleniyor. İstekler gecikmeye başlamadan önce, X-RateLimit-Delay dışında tüm bu üst bilgiler gönderilir. Bu tasarım, istemcilerin istek oranını proaktif olarak yavaşlatmalarına olanak tanır.

Başlık Adı

Açıklama

Retry-After

Rfc 6585 tarafından belirtilen üst bilgi, bir sonraki isteğinizi göndermeden önce algılama eşiğinin altına düşmek için ne kadar beklemeniz gerektiğini size bildirir. Birimler: saniye.

X-RateLimit-Resource

Ulaşılan hizmetin ve eşiğin türünü gösteren özel üst bilgi. Eşik türleri ve hizmet adları zaman içinde ve uyarı olmadan değişebilir. Bu dizeyi bir insana görüntülemenizi öneririz, ancak hesaplama için bu dizeye güvenmemenizi öneririz.

X-RateLimit-Delay

İsteğin gecikme süresi ne kadar. Birimler: en fazla üç ondalık basamak içeren saniye (milisaniye).

X-RateLimit-Limit

Gecikmeler uygulanmadan önce izin verilen toplam TSTU sayısı.

X-RateLimit-Remaining

Gecikmelerin başlamasından önce kalan TSTU sayısı. İstekler zaten gecikmiş veya engellenmişse 0'dır.

X-RateLimit-Reset

Kaynak tüketimi tamamen durduğunda izlenen kullanımın 0 TSTU'ya döneceği zaman. Unix dönem süresiyle ifade edilir.

İş izleme, işlem ve proje sınırları

Azure DevOps, bir kuruluşta sahip olabileceğiniz proje sayısını ve her projede sahip olabileceğiniz ekip sayısını sınırlar. İş öğeleri, sorgular, kuyruklar, panolar, gösterge panoları ve daha fazlası için de sınırlar vardır. Daha fazla bilgi için bkz. İş izleme, işlem ve proje sınırları.

Viki

Her zamanki depo sınırlarına ek olarak, bir projedeki wiki dosyası 25 MB'a kadar olabilir.

Hizmet bağlantıları

Hizmet bağlantıları oluşturma konusunda proje başına sınır yoktur. Ancak, sınırlar Microsoft Entra Id aracılığıyla uygulanabilir. Daha fazla bilgi için aşağıdaki makalelere bakın:

İlgili içerik

  • Last updated on