Hız sınırları

  • Makale
  • Okumak için 3 dakika

Retry-After

RfC 6585belirtilen üst bilgisi, bir sonraki isteğinizi göndermeden önce algılama eşiğinin altına düşmesi için ne kadar beklemeniz gerekir? Birimler: saniye.

X-RateLimit-Resource

Hizmeti ve ulaşıldı eşiğin türünü belirten özel üst bilgi. Eşik türleri ve hizmet adları zaman içinde ve uyarı olmadan değişebilir. Bu dizeyi bir insan için görüntülemenizi öneririz, ancak hesaplama için bu dizeye güvenmenizi önerilmez.

X-RateLimit-Delay

İsteğin ne kadar gecikmeli olduğu. Birimler: 3 ondalık basamağa (milisaniye) kadar olan saniye.

X-RateLimit-Limit

Gecikmeler uygulanmadan önce izin verilen toplam TST'ler sayısı.

X-RateLimit-Remaining

Gecikmeden önce kalan TST'ların sayısı. İstekler zaten gecikiyor veya engellenmişse 0 olur.

X-RateLimit-Reset

Tüm kaynak tüketiminin hemen durdurulursa, izlenilen kullanımın 0 TSTUs'a geri dönebilirsiniz. Unix dönemi zamanında ifade edildi.

Öneriler

En azından üst bilgiye yanıt vermenizi Retry-After öneririz. Herhangi bir yanıtta Retry-After üst bilgi algılarsanız, başka bir istek göndermeden önce bu süre geçene kadar bekleyin. Bunu yapmak, istemci uygulamanıza daha az zorlanan gecikmeler yaşamanıza yardımcı olur. Yanıtın 200 olduğunu, bu nedenle istekte yeniden deneme mantığı uygulamanın gerekmey olduğunu unutmayın.

Mümkünse, ve üst bilgilerini de X-RateLimit-RemainingX-RateLimit-Limit izlemenizi öneririz.

Bunu yapmak gecikme eşiğine ne kadar hızlı yaklaştığını tahmin etmek için size olanak sağlar.

İstemciniz, isteklerini zaman içinde yayarak akıllı bir şekilde tepki ve destek olabilir.

Azure DevOps Services

Azure DevOps birçok hizmet olarak yazılım çözümü gibi, maliyetleri azaltmak ve performansı geliştirmek için çok müşterili bir çözüm kullanır. Bu tasarım, diğer kullanıcıların, paylaşılan kaynaklarının tüketiminde ani artışlar olduğunda kullanıcıları performans sorunlarına ve hatta kesintilere karşı savunmasız bırakır. Bu sorunları çözmek Azure DevOps kişilerin tükettiği kaynakları ve belirli komutlara ne kadar istekte bulundurlarını sınırlar. Bu sınırlar aşılırsa, gelecekteki istekler gecikebilir veya engellenmiş olabilir.

Kullanıcının istekleri önemli miktarda geciktirilirse, bu kullanıcı bir e-posta alır ve web'de bir uyarı başlığı görür. Derleme hizmeti hesabı ve e-posta adresi olmayan diğer kullanıcılar için, Project Koleksiyon Yöneticileri grubunun üyeleri e-postayı alır. Daha fazla bilgi için bkz. Kullanım izleme.

Tek bir kullanıcının istekleri engellenmiş olduğunda, HTTP kodu 429 (çok fazla istek) olan yanıtlar ve aşağıdaki iletiye benzer bir ileti alır:

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

Geçerli hız sınırları

Azure DevOps genel tüketim limiti vardır. Bu sınır, paylaşılan kaynaklar bunalma tehlikesinde olduğunda tek tek kullanıcılardan gelen istekleri eşiğin ötesinde geciktiriyor.

Genel tüketim sınırı

Bu sınır yalnızca paylaşılan kaynaklar bunalmak zorunda olmaya yaklaşacaksa kesintileri önlemeye odaklandı. Bireysel kullanıcıların istekleri genellikle yalnızca aşağıdakilerden biri oluştuğunda geciktirilir:

  • Paylaşılan kaynaklarından biri bunalma riskiyle karşı
  • Kişisel kullanımları, (kayan) beş dakikalık bir süre içinde tipik bir kullanıcının kullanımının 200 katını aşıyor

Gecikme süresi, kullanıcının sürdürülebilir tüketim düzeyine bağlıdır. Gecikmeler istek başına birkaç milisaniye ile 30 saniye arasında olabilir. Tüketim sıfıra iner veya kaynak artık bunalmazsa, gecikmeler beş dakika içinde durur. Tüketim yüksek kalırsa, kaynağı korumak için gecikmeler süresiz olarak devam eder.

Azure DevOps birimleri (TSTU)

Azure DevOps paylaşılan birçok kaynak tüketir ve tüketim birçok faktöre bağlıdır. Örnek:

  • Sürüm denetimine çok sayıda dosya yüklemek, veritabanlarında ve depolama hesaplarda büyük miktarda yük oluşturur.
  • Karmaşık iş öğesi izleme sorguları, aray oluşturdukları iş öğelerinin sayısına göre veritabanı yükü oluşturur.
  • Sürüm denetiminden dosya indirerek, günlük çıktısı üreterek ve bu şekilde devam ettiyerek sürücü yüklemesi oluşturur.
  • Tüm işlemler, hizmetin çeşitli kısımlarında CPU ve bellek kullanır.

Tüm bu durumlara uyum Azure DevOps kaynak tüketimi, Azure DevOps birimleri veya TSTUS olarak adlandırılan soyut birimlerle ifade edildi.

TSTUs sonunda aşağıdakilerin bir karışımını içerir:

Azure SQL Veritabanları en yaygın olarak aşırı tüketime maruz olan paylaşılan kaynaklar olduğu için şimdilik TST'ler öncelikli olarak Azure SQL Veritabanı DTUS'lara odaklanmaktadır.

Tek bir TSTU, tek bir normal kullanıcıdan beş dakikada bir Azure DevOps ortalama yük olur. Normal kullanıcılar da yükte ani artışlar üretir. Bu ani artışlar genellikle beş dakikada 10 veya daha az TSTUs olur. Daha az sıklıkta, ani artışlar 100 TSTU'ya kadar yüksektir. Küresel tüketim sınırı, kayan beş dakikalık bir pencerede 200 TSTUs'tır.

Pipelines

Hız sınırlaması, Azure Pipelines. Her işlem hattı, kendi kaynak tüketimi izne sahip tek bir varlık olarak kabul edilir. Derleme aracıları kendi içinde barındırıldıklarında bile, kopyalama ve günlük gönderme şeklinde yük üretirler.

Kayan 5 dakikalık bir pencerede tek bir işlem hattı için 200 TSTU sınırı uygulanır. Bu sınır, kullanıcılar için genel tüketim sınırıyla aynıdır. İşlem hattı hız sınırlaması nedeniyle geciktirilir veya engellenirse, ekli günlüklerde bir ileti görüntülenir.

API istemcisi deneyimi

İstekler gecikmeli veya engellenmiş olduğunda, Azure DevOps API istemcilerinin tepki vermelerine yardımcı olmak için yanıt üst bilgileri döndürür. Tam olarak standartlaştırılamasa da, bu üst bilgiler diğer popüler hizmetlerle geniş bir şekilde aynı şekildedir.

Aşağıdaki tabloda kullanılabilir üst bilgiler ve bunların anlamı listelanmıştır. dışında, X-RateLimit-Delay istekler gecikmeye başlamadan önce bu üst bilgilerin hepsi gönderilir. Bu tasarım, istemcilere istek oranını proaktif olarak yavaşlatma fırsatı verir.

Üst bilgi adı

Açıklama