Limiti di frequenza e utilizzo

  • Articolo

Servizi di Azure DevOps

Azure DevOps Services usa 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 presentano picchi di consumo. Azure DevOps limita quindi le risorse che gli 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.

Per altre informazioni, vedere Limiti Git e Procedure consigliate per evitare di raggiungere i limiti di frequenza.

Limite di consumo globale

Azure DevOps ha attualmente un limite di consumo globale, che ritarda le richieste dei singoli utenti oltre una soglia quando le risorse condivise sono in pericolo di essere sovraccaricate. Questo limite è incentrato esclusivamente sull'evitare interruzioni quando le risorse condivise sono vicine a essere sovraccaricate. I singoli utenti ricevono in genere richieste posticipate solo quando si verifica uno degli eventi imprevisti seguenti:

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

La quantità di ritardo dipende dal livello di consumo sostenuto dell'utente. I ritardi sono compresi tra alcuni millisecondi per richiesta fino a 30 secondi. Una volta che l'utilizzo passa a zero o la risorsa non viene più sovraccaricata, i ritardi si arrestino entro cinque minuti. Se l'utilizzo rimane elevato, i ritardi potrebbero continuare a tempo indeterminato per proteggere la risorsa.

Quando una richiesta utente viene ritardata da una quantità significativa, l'utente riceve un messaggio di posta elettronica e 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 Raccolta progetti Amministrazione istrators ricevono 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>.

Unità elaborate di Azure DevOps (TSTU)

Gli utenti di Azure DevOps usano molte risorse condivise e il consumo dipende dai fattori seguenti:

  • Il caricamento di un numero elevato di file nel controllo della versione crea una grande quantità di carico su database e account di archiviazione
  • Le query complesse di rilevamento degli elementi di lavoro creano il carico del database in base al numero di elementi di lavoro cercati
  • Compila il carico dell'unità scaricando i file dal controllo della versione, producendo l'output del log
  • Tutte le operazioni utilizzano CPU e memoria in varie parti del servizio

Per adattarsi, l'utilizzo delle risorse di Azure DevOps è espresso in unità astratte denominate unità elaborate di Azure DevOps o TSTU. Le TSTU incorporano infine una miscela degli elementi seguenti:

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

Per il momento, le TSTU sono principalmente incentrate sulle DTU database SQL di Azure, poiché le database SQL di Azure sono le risorse condivise più comunemente sovraccaricate da un consumo eccessivo. Un singolo TSTU è il carico medio previsto da un singolo utente normale di Azure DevOps per generare ogni 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 superano i 100 TSTU.

Il limite di consumo globale è di 200 TSTU entro un intervallo di cinque minuti scorrevole.

È consigliabile almeno rispondere all'intestazione Retry-After . Se si rileva un'intestazione Retry-After in qualsiasi risposta, attendere che venga trascorso del tempo prima di inviare un'altra richiesta. In questo modo, l'esperienza dell'applicazione client comporta 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 X-RateLimit-Remaining e X-RateLimit-Limit intestazioni. In questo modo è possibile approssimare la velocità con cui si sta raggiungendo la soglia di ritardo. Il client può reagire in modo intelligente e distribuire le richieste nel tempo.

Nota

Le identità usate da strumenti e applicazioni per l'integrazione con Azure DevOps potrebbero richiedere limiti di utilizzo e velocità superiori al limite di consumo consentito da tempo a tempo. È possibile ottenere limiti di frequenza e utilizzo aggiuntivi assegnando il livello di accesso Basic + Test Plans alle identità desiderate usate dall'applicazione. Dopo aver soddisfatto la necessità di limiti di frequenza più elevati, è possibile tornare al livello di accesso usato dall'identità. Viene addebitato il costo del livello di accesso Basic + Test Plans solo per il tempo assegnato all'identità.

Le identità a cui è già stata assegnata una sottoscrizione di Visual Studio Enterprise non possono essere assegnate livello di accesso Basic + Test Plans finché non vengono rimosse.

Pipeline

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

Si applica un limite di 200 TSTU per una singola pipeline in una finestra temporale scorrevole di 5 minuti. Questo limite è uguale al 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 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 più diffusi.

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

Nome dell'intestazione

Descrizione

Retry-After

L'intestazione specificata da RFC 6585 inviata 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 dei servizi possono variare nel tempo e senza avvisi. È consigliabile visualizzare questa stringa in un essere umano, ma non basarsi su di esso per il calcolo.

X-RateLimit-Delay

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

X-RateLimit-Limit

Numero totale di TSTU consentite prima che vengano imposti ritardi.

X-RateLimit-Remaining

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

X-RateLimit-Reset

Ora in cui, se tutto l'utilizzo delle risorse è stato interrotto immediatamente, l'utilizzo rilevato tornerebbe a 0 TSTU. Espresso in tempo dell'epoca Unix.

Rilevamento del lavoro, processo e limiti dei progetti

Azure DevOps impone limiti per il numero di progetti che è possibile avere in un'organizzazione e il numero di team che è possibile avere all'interno di ogni progetto. Tenere inoltre presente i limiti per gli elementi di lavoro, le query, i backlog, le bacheche, i dashboard e altro ancora. Per altre informazioni, vedere Rilevamento del lavoro, processo e limiti dei progetti.

Wiki

Oltre ai soliti limiti del repository, i wiki definiti per un progetto sono limitati a 25 MB per singolo file.

Connessioni al servizio

Non sono previsti limiti per progetto per la creazione di connessioni al servizio. Tuttavia, potrebbero esserci limiti, che vengono imposti tramite Microsoft Entra ID. Per altre informazioni, vedere gli articoli seguenti: