Limiti di velocità

Azure DevOps Services

Azure DevOps, come molte soluzioni software-as-a-service, usa multi-tenancy per ridurre i costi e migliorare le prestazioni. Questa progettazione lascia gli utenti vulnerabili ai problemi di prestazioni e alle interruzioni quando altri utenti, delle risorse condivise, hanno picchi nel consumo. Per combattere questi problemi, Azure DevOps limita le risorse che i singoli utenti possono usare e la quantità di richieste che possono effettuare a determinati comandi. Quando questi limiti vengono superati, le richieste future potrebbero essere ritardate o bloccate.

Quando le richieste di un utente vengono ritardate per un importo significativo, l'utente riceve un messaggio di posta elettronica e visualizza un banner di avviso nel Web. Per l'account del servizio di compilazione e altri senza un indirizzo di posta elettronica, i membri del gruppo Amministratori raccolta progetto ricevono il messaggio di posta elettronica. Per altre informazioni, vedere Monitoraggio dell'utilizzo.

Quando le richieste di un singolo utente vengono bloccate, le risposte con codice HTTP 429 (troppe richieste) vengono ricevute, con un messaggio simile al seguente:

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

Per altre informazioni, vedere gli articoli seguenti:

Limiti di frequenza correnti

Azure DevOps ha attualmente un limite di consumo globale. Questo limite ritarda le richieste da singoli utenti oltre una soglia quando le risorse condivise sono in pericolo di sovraccarico.

Limite di consumo globale

Questo limite è incentrato esclusivamente sull'evitare interruzioni quando le risorse condivise sono vicine al sovraccarico. I singoli utenti in genere hanno solo le richieste ritardate quando si verifica uno dei seguenti:

  • Una delle risorse condivise è a rischio di essere sopraffatti
  • Il loro utilizzo personale supera 200 volte il consumo di un utente tipico all'interno di una finestra di cinque minuti (scorrevole)

La quantità di ritardo dipende dal livello di consumo sostenuto dall'utente. I ritardi vanno da pochi millisecondi per richiesta fino a 30 secondi. Una volta che l'utilizzo passa a zero o la risorsa non è più sovraccaricata, i ritardi si arrestano entro cinque minuti. Se l'utilizzo rimane elevato, i ritardi potrebbero continuare in modo indefinito per proteggere la risorsa.

Unità di velocità effettiva di Azure DevOps (TSTUs)

Gli utenti di Azure DevOps usano molte risorse condivise e il consumo dipende da molti fattori. Ad esempio:

  • Il caricamento di un numero elevato di file nel controllo della versione crea una grande quantità di carico nei database e sugli account di archiviazione.
  • Le query di rilevamento degli elementi di lavoro complesse creano il carico del database in base al numero di elementi di lavoro che eseguono la ricerca.
  • Compila il carico dell'unità scaricando i file dal controllo della versione, generando l'output del log e così via.
  • Tutte le operazioni usano CPU e memoria in varie parti del servizio.

Per supportare tutto questo, l'utilizzo delle risorse di Azure DevOps è espresso in unità astratte denominate unità di velocità effettiva di Azure DevOps o TSTUS.

Le TSTU incorporano infine una miscela dei seguenti elementi:

  • Azure SQL DTU del database come misura dell'utilizzo del database
  • Livello applicazione e CPU dell'agente di processo, memoria e I/O come misura del consumo di calcolo
  • Larghezza di banda di Archiviazione di Azure come misura del consumo di archiviazione

Per il momento, le unità TST sono principalmente incentrate sulle DTU del database Azure SQL, poiché Azure SQL Database sono le risorse condivise più comunemente sovraccaricate da un consumo eccessivo.

Un singolo TSTU è il carico medio previsto per un singolo utente normale di Azure DevOps per generare al massimo cinque minuti. Gli utenti normali generano anche picchi di carico. Questi picchi sono in genere 10 o meno TSTU per cinque minuti. Meno frequentemente, i picchi vanno fino a 100 TSTUs. Il limite di consumo globale è 200 TSTU entro una finestra scorrevole di cinque minuti.

Pipelines

La limitazione della frequenza è simile per Azure Pipelines. Ogni pipeline viene considerata come un'entità singola con il proprio consumo di risorse monitorata. Anche se gli agenti di compilazione sono self-hosted, generano il carico sotto forma di clonazione e invio di log.

Si applica un limite TSTU 200 per una singola pipeline in una finestra scorrevole di 5 minuti. Questo limite è uguale al limite di consumo globale per gli utenti. Se una pipeline è ritardata o bloccata dalla limitazione della frequenza, viene visualizzato un messaggio nei log collegati.

Esperienza client API

Quando le richieste vengono ritardate o bloccate, Azure DevOps restituisce le intestazioni di risposta per aiutare i client API a reagire. Sebbene non siano completamente standardizzate, queste intestazioni sono ampiamente in linea con altri servizi popolari.

Nella tabella seguente sono elencate le intestazioni disponibili e ciò che significano. X-RateLimit-DelayAd eccezione di , tutte queste intestazioni vengono inviate prima che le richieste inizino a essere ritardate. Questa progettazione offre ai clienti l'opportunità di rallentare in modo proattivo il tasso di richieste.

Nome dell'intestazione

Descrizione


Retry-After

L'intestazione RFC 6585 specificata invia per indicare quanto tempo attendere prima di inviare la richiesta successiva per rientrare nella soglia di rilevamento. Unità: secondi.


X-RateLimit-Resource

Intestazione personalizzata che indica il servizio e il tipo di soglia raggiunto. I tipi di soglia e i nomi di servizio possono variare nel tempo e senza avviso. È consigliabile visualizzare questa stringa in un oggetto umano, ma non basandosi su di esso per il calcolo.


X-RateLimit-Delay

Tempo di ritardo della richiesta. Unità: secondi con fino a tre cifre decimali (millisecondi).


X-RateLimit-Limit

Numero totale di unità TST consentite prima che vengano imposti ritardi.


X-RateLimit-Remaining

Numero di TSTus rimanenti prima di essere ritardato. Se le richieste sono già ritardate o bloccate, è 0.


X-RateLimit-Reset

Tempo in cui, se l'utilizzo di tutte le risorse è stato arrestato immediatamente, l'utilizzo monitorato restituirà 0 TSTU. Espresso nell'epoca Unix.


Consigli

È consigliabile rispondere almeno all'intestazione Retry-After . Se si rileva un'intestazione Retry-After in qualsiasi risposta, attendere fino a quando tale quantità di tempo non è passata prima di inviare un'altra richiesta. In questo modo, l'applicazione client ha meno ritardi applicati. Tenere presente che la risposta è 200, quindi non è necessario applicare la logica di ripetizione dei tentativi alla richiesta.

Se possibile, è consigliabile monitorare e X-RateLimit-Limit monitorare X-RateLimit-Remaining le intestazioni.

In questo modo è possibile approssimare la velocità con cui si avvicina la soglia di ritardo.

Il client può reagire in modo intelligente distribuendo le proprie richieste nel corso del tempo.