Limiti di velocità


Retry-After

L'intestazione RFC 6585-specified inviata per indicare il tempo di attesa 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 raggiunti. I tipi di soglia e i nomi dei servizi possono variare nel tempo e senza preavviso. È consigliabile visualizzare questa stringa a un essere umano, ma non basarsi su di essa per il calcolo.


X-RateLimit-Delay

Tempo di ritardo della richiesta. Unità: secondi con un massimo di 3 cifre decimali (millisecondi).


X-RateLimit-Limit

Numero totale di TSTU consentite prima dell'imposizione dei ritardi.


X-RateLimit-Remaining

Numero di TSTU rimanenti prima di essere posticipate. Se le richieste sono già in ritardo o bloccate, è 0.


X-RateLimit-Reset

Ora in cui, se tutto il consumo di risorse si è arrestato immediatamente, l'utilizzo monitorato tornerà a 0 TSTU. Espresso nel tempo di un'era Unix.


Consigli

È consigliabile rispondere almeno Retry-After all'intestazione. Se si rileva un'intestazione in una risposta, attendere che sia trascorsa tale quantità di Retry-After tempo prima di inviare un'altra richiesta. Questa operazione consente all'applicazione client di sperimentare un minor numero di 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-RemainingX-RateLimit-Limit le intestazioni.

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

Il client può reagire in modo intelligente stendendo le richieste nel tempo.

Azure DevOps Services

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

Quando le richieste di un utente vengono ritardate di una quantità significativa, tale utente riceve un messaggio di posta elettronica e visualizza un banner di avviso nel Web. Per l'account del servizio di compilazione e altri utenti senza un indirizzo di posta elettronica, i membri del gruppo Project amministratori della raccolta ottengono il messaggio di posta elettronica. Per altre informazioni, vedere Monitoraggio dell'utilizzo.

Quando le richieste di un singolo utente vengono bloccate, vengono ricevute risposte con codice HTTP 429 (troppe richieste), 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>.

Limiti di frequenza correnti

Azure DevOps ha attualmente un limite di consumo globale. Questo limite ritarda le richieste dei singoli utenti oltre una soglia quando le risorse condivise rischiano di essere sovraccaricate.

Limite di consumo globale

Questo limite è incentrato esclusivamente sull'evitare interruzioni quando le risorse condivise sono quasi sovraccariche. I singoli utenti in genere hanno le richieste ritardate solo quando si verifica una delle condizioni seguenti:

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

L'importo del ritardo dipende dal livello di consumo dell'utente. I ritardi variano da pochi millisecondi per ogni richiesta fino a 30 secondi. Quando l'utilizzo è pari a zero o la risorsa non viene più sovraccaricata, i ritardi si arrestano entro cinque minuti. Se il consumo rimane elevato, i ritardi possono continuare per un periodo indefinito per proteggere la risorsa.

Azure DevOps unità elaborate (TSTU)

Azure DevOps utenti utilizzano 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 sui 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 in cui vengono eseguite ricerche.
  • Le compilazioni generano il carico scaricando i file dal controllo della versione, producendo l'output del log e così via.
  • Tutte le operazioni utilizzano CPU e memoria in varie parti del servizio.

Per supportare tutto questo, Azure DevOps consumo di risorse è espresso in unità astratte denominate unità Azure DevOps elaborate o TSTU.

Le TSTU incorporano infine una combinazione di quanto segue:

  • database SQL di Azure DTO come misura dell'utilizzo del database
  • Cpu, memoria e I/O del livello applicazione e dell'agente di processo come misura del consumo di calcolo
  • Archiviazione di Azure larghezza di banda come misura del consumo di archiviazione

Per il momento, le TSTU sono incentrate principalmente sulle DTO database SQL di Azure, poiché i database di Azure SQL sono le risorse condivise più comunemente sovraccaricate da un consumo eccessivo.

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

Pipelines

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

Viene applicato un limite di 200 TSTU per una singola pipeline in una finestra scorrevole di 5 minuti. Questo limite è lo stesso del limite di consumo globale per gli utenti. Se una pipeline viene ritardata o bloccata dalla limitazione della frequenza, nei log allegati viene visualizzato un messaggio.

Esperienza client API

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

Nella tabella seguente sono elencate le intestazioni disponibili e il significato. Ad eccezione X-RateLimit-Delay di , tutte queste intestazioni vengono inviate prima che le richieste inizino a essere ritardate. Questa progettazione offre ai client la possibilità di rallentare in modo proattivo la frequenza delle richieste.

Nome dell'intestazione

Descrizione