Condividi tramite

Limiti di frequenza e utilizzo

Servizi di Azure DevOps

Azure DevOps Services usa multi-tenancy per ridurre i costi e migliorare le prestazioni. Questa progettazione può causare problemi di prestazioni o interruzioni quando altri utenti di risorse condivise presentano picchi di consumo. Per evitare questo problema, Azure DevOps limita le risorse che ogni utente può usare e il numero di richieste che possono effettuare a determinati comandi. Se si superano questi limiti, le richieste future possono 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 un limite di consumo globale che ritarda le richieste dei singoli utenti quando le risorse condivise sono a rischio di sovraccarico. Questo limite consente di evitare interruzioni quando le risorse condivise sono vicine al sovraccarico. I singoli utenti riscontrano in genere richieste ritardate solo quando si verifica uno degli eventi imprevisti seguenti:

  • Una delle risorse condivise rischia di essere sovraccaricata.
  • L'utilizzo personale supera le 200 volte il consumo di un utente tipico in una finestra scorrevole di cinque minuti.

Il ritardo dipende dal livello di consumo sostenuto dell'utente. I ritardi sono compresi tra alcuni millisecondi per richiesta fino a 30 secondi. Quando l'utilizzo scende a zero o la risorsa non viene sovraccaricata, i ritardi si arrestino entro cinque minuti. Se l'utilizzo rimane elevato, i ritardi possono continuare a tempo indeterminato per proteggere la risorsa.

Quando una richiesta utente viene ritardata da un notevole ritardo, l'utente riceve un messaggio di posta elettronica e un banner di avviso sul web. Per l'account del servizio di compilazione e altri senza un indirizzo di posta elettronica, i membri del gruppo Project Collection Administrators ricevono il messaggio di posta elettronica. Per altre informazioni, vedere Monitoraggio dell'utilizzo.

Quando le richieste di un singolo utente vengono bloccate, l'utente riceve risposte con codice HTTP 429 (troppe richieste) e 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à di throughput di Azure DevOps

Gli utenti di Azure DevOps usano molte risorse condivise e il livello di utilizzo dipende da fattori come:

  • Caricamento di un numero elevato di file nel controllo di versione, che aumenta il carico su database e account di archiviazione.
  • Esecuzione di query complesse sugli elementi di lavoro, che aumentano il carico del database in base al numero di elementi di lavoro in cui viene eseguita la ricerca.
  • Esecuzione di compilazioni, che scaricano i file dal controllo di versione e producono il registro di log.
  • Operazioni generali, che utilizzano CPU e memoria in diverse parti del servizio.

Per misurare questa attività, Azure DevOps esprime il consumo delle risorse in unità di throughput di Azure DevOps (TSTU). Un oggetto TSTU è un'unità di carico astratta che rappresenta una combinazione di risorse diverse, tra cui:

  • Utilizzo del database, misurato principalmente tramite DTU del database SQL di Azure.
  • Utilizzo delle risorse di calcolo: CPU, memoria e I/O dai livelli dell'applicazione e agenti di lavoro.
  • Utilizzo dell'archiviazione: larghezza di banda di Archiviazione di Azure.

Annotazioni

Le TSTU sono intenzionalmente astratte. Aggregano il consumo delle risorse tra livelli di calcolo, archiviazione e database all'interno di un'infrastruttura distribuita. Le metriche sottostanti (CPU, memoria, I/O, DTU) non sono direttamente esposte o significative autonomamente. Le TSTU offrono un modo unificato per rappresentare il carico, semplificando la gestione e il monitoraggio dell'utilizzo senza esporre la complessità completa dei singoli componenti delle risorse. Non è possibile calcolare l'utilizzo in TSTU per un'azione con una formula, ma è possibile visualizzare il numero di TSTU utilizzate da un'operazione nella pagina di monitoraggio dell'utilizzo . Alcune operazioni, ad esempio le query sugli elementi di lavoro, variano in termini di utilizzo man mano che l'organizzazione cresce e cambia, quindi potrebbe essere necessario fare il benchmarking periodicamente per mantenere l'accuratezza.

Attualmente, le TSTU si concentrano principalmente sulle DTU del database SQL di Azure perché i database sono la risorsa condivisa che è più probabile che venga sovraccaricata da un consumo eccessivo.

  • Una TSTU rappresenta il carico medio generato da un utente tipico di Azure DevOps in cinque minuti.
  • La normale attività utente può generare picchi di 10 TSTU o meno per cinque minuti.
  • Picchi più grandi ma meno frequenti possono raggiungere fino a 100 TSTU.
  • Il limite globale è di 200 TSTU entro qualsiasi finestra temporale scorrevole di cinque minuti.

Procedure consigliate

  • Rispettare l'intestazione Retry-After: se la si riceve in una risposta, attendere l'ora specificata prima di inviare un'altra richiesta. La risposta restituisce comunque HTTP 200, quindi la logica di ripetizione dei tentativi non è necessaria.
  • Monitorare le intestazioni X-RateLimit: se disponibili, tenere traccia di X-RateLimit-Remaining e X-RateLimit-Limit per approssimare quanto rapidamente si sta avvicinando alla soglia. Ciò consente al client di attenuare i picchi di richieste ed evitare ritardi forzati.

Annotazioni

Le identità usate da strumenti e applicazioni per l'integrazione con Azure DevOps possono talvolta richiedere limiti di utilizzo e velocità superiori al limite di consumo consentito. Aumentare questi limiti assegnando il livello di accesso Basic + Test Plans alle identità usate dall'applicazione. Dopo che non sono più necessari limiti di frequenza più elevati, ripristinare il livello di accesso precedente. Ti verranno addebitati i costi per il livello di accesso Basic + Test Plans solo per la durata assegnata all'identità. Alle identità già assegnate una sottoscrizione di Visual Studio Enterprise non è possibile assegnare il livello di accesso Basic + Test Plans finché non si rimuove la sottoscrizione.

Le pipeline

La limitazione della frequenza funziona allo stesso modo per Azure Pipelines. Ogni pipeline è una singola entità e il relativo consumo di risorse viene monitorato separatamente. Anche se gli agenti di compilazione sono ospitati localmente, generano carico clonando e inviando log.

C'è un limite di 200 TSTU per ogni pipeline in una finestra scorrevole di 5 minuti. Questo limite corrisponde al limite di consumo globale per gli utenti. Se la limitazione della frequenza ritarda o blocca una pipeline, viene visualizzato un messaggio nei log allegati.

Esperienza del cliente 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 loro significato. Ad eccezione di X-RateLimit-Delay, tutte queste intestazioni vengono inviate prima che le richieste inizino a subire ritardi. Questa progettazione consente ai client di rallentare in modo proattivo la frequenza di richieste.

Nome dell'intestazione

Descrizione

Retry-After

L'intestazione specificata da RFC 6585 è inviata per informarti su quanto tempo attendere prima di inviare la tua prossima richiesta per rimanere al di sotto della 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 consentiti prima che vengano imposti ritardi.

X-RateLimit-Remaining

Numero di TSTUs rimanenti prima che i ritardi inizino. Se le richieste sono già ritardate o bloccate, è 0.

X-RateLimit-Reset

Ora in cui, se l'utilizzo di tutte le risorse si arresta immediatamente, l'utilizzo rilevato torna a 0 TSTU. Espresso in tempo dell'epoca Unix.

Rilevamento del lavoro, processo e limiti dei progetti

Azure DevOps limita il numero di progetti che è possibile avere in un'organizzazione e il numero di team che è possibile avere in ogni progetto. Esistono anche limiti per elementi di lavoro, query, backlog, bacheche, dashboard e altro ancora. Per altre informazioni, vedere Rilevamento del lavoro, processo e limiti dei progetti.

Wiki

Oltre ai soliti limiti del repository, un file wiki in un progetto può avere un massimo di 25 MB.

Connessioni al servizio

Non esistono limiti per progetto per la creazione di connessioni al servizio. Tuttavia, i limiti potrebbero essere imposti tramite Microsoft Entra ID. Per altre informazioni, vedere gli articoli seguenti:

Contenuti correlati

  • Last updated on