Gestione degli errori temporanei
Tutte le applicazioni che comunicano con servizi e risorse remoti devono essere sensibili agli errori temporanei. Ciò vale soprattutto per le applicazioni eseguite nel cloud, in cui, a causa della natura dell'ambiente e della connettività tramite Internet, è probabile che questo tipo di errore venga rilevato più spesso. Gli errori temporanei includono la perdita momentanea della connettività di rete ai componenti e ai servizi, l'indisponibilità temporanea di un servizio e i timeout che si verificano quando un servizio è occupato. Questi errori sono spesso auto-corretti, quindi, se l'azione viene ripetuta dopo un ritardo appropriato, è probabile che abbia esito positivo.
Questo articolo fornisce indicazioni generali per la gestione degli errori temporanei. Per informazioni sulla gestione degli errori temporanei quando si usano i servizi di Azure, vedere Linee guida per i tentativi per i servizi di Azure.
Perché si verificano errori temporanei nel cloud?
Gli errori temporanei possono verificarsi in qualsiasi ambiente, su qualsiasi piattaforma o sistema operativo e in ogni tipo di applicazione. Per le soluzioni eseguite nell'infrastruttura locale locale, le prestazioni e la disponibilità dell'applicazione e dei relativi componenti vengono in genere mantenute tramite ridondanza hardware costosa e spesso sottoutilata e i componenti e le risorse si trovano vicini tra loro. Questo approccio rende meno probabile l'errore, ma possono verificarsi errori temporanei, in quanto possono verificarsi interruzioni causate da eventi imprevisti come l'alimentatore esterno o i problemi di rete o altri scenari di emergenza.
L'hosting nel cloud, anche in sistemi cloud privati, può offrire una maggiore disponibilità complessiva attraverso risorse condivise, ridondanza, failover automatico e allocazione dinamica delle risorse su molti nodi di calcolo specifici. Tuttavia, a causa della natura degli ambienti cloud, è più probabile che si verifichino errori temporanei. per vari motivi:
Molte risorse in un ambiente cloud vengono condivise e l'accesso a queste risorse è soggetto a limitazioni per proteggere le risorse. Alcuni servizi rifiutano le connessioni quando il carico aumenta a un livello specifico o quando viene raggiunta una velocità effettiva massima, per consentire l'elaborazione delle richieste esistenti e mantenere le prestazioni del servizio per tutti gli utenti. La limitazione consente di mantenere la qualità del servizio per i vicini e altri tenant che usano la risorsa condivisa.
Gli ambienti cloud usano un numero elevato di unità hardware di base. Offrono prestazioni distribuendo dinamicamente il carico tra più unità di calcolo e componenti dell'infrastruttura. Offrono affidabilità riciclando o sostituendo automaticamente le unità non riuscite. A causa di questa natura dinamica, possono verificarsi occasionalmente errori temporanei di connessione e errori di connessione temporanei.
Sono spesso presenti più componenti hardware, tra cui l'infrastruttura di rete, ad esempio router e servizi di bilanciamento del carico, tra l'applicazione e le risorse e i servizi usati. Questa infrastruttura aggiuntiva può talvolta introdurre ulteriore latenza di connessione ed errori di connessione temporanei.
Le condizioni di rete tra il client e il server potrebbero essere variabili, soprattutto quando la comunicazione attraversa Internet. Anche nelle posizioni locali, i carichi di traffico pesanti possono rallentare la comunicazione e causare errori di connessione intermittenti.
Problematiche
Gli errori temporanei possono avere un grande effetto sulla disponibilità percepita di un'applicazione, anche se sono stati testati accuratamente in tutte le circostanze prevedibili. Per garantire che le applicazioni ospitate nel cloud funzionino in modo affidabile, è necessario assicurarsi che possano rispondere alle sfide seguenti:
L'applicazione deve essere in grado di rilevare gli errori quando si verificano e determinare se gli errori sono probabilmente temporanei, sono di lunga durata o sono errori del terminale. È probabile che risorse diverse restituiscano risposte diverse quando si verifica un errore e queste risposte possono variare anche a seconda del contesto dell'operazione. Ad esempio, la risposta per un errore quando l'applicazione legge dall'archiviazione potrebbe differire dalla risposta per un errore durante la scrittura nell'archiviazione. Molte risorse e servizi hanno contratti di errore temporanei ben documentati. Tuttavia, quando tali informazioni non sono disponibili, può essere difficile individuare la natura dell'errore e se è probabile che sia temporaneo.
L'applicazione deve essere in grado di ripetere l'operazione se determina che è probabile che l'errore sia temporaneo. Deve inoltre tenere traccia del numero di tentativi di esecuzione dell'operazione.
L'applicazione deve usare una strategia appropriata per i tentativi. La strategia specifica il numero di tentativi dell'applicazione, il ritardo tra ogni tentativo e le azioni da eseguire dopo un tentativo non riuscito. Il numero appropriato di tentativi e il ritardo tra ognuno di essi sono spesso difficili da determinare. La strategia varia a seconda del tipo di risorsa e delle condizioni operative correnti della risorsa e dell'applicazione.
Linee guida generali
Le linee guida seguenti consentono di progettare meccanismi di gestione degli errori temporanei appropriati per le applicazioni.
Determinare se è presente un meccanismo di ripetizione dei tentativi predefinito
Molti servizi forniscono una libreria client o SDK che include un meccanismo di gestione degli errori temporanei. I criteri di ripetizione usati si basano in genere sulla natura e sui requisiti del servizio di destinazione. In alternativa, le interfacce REST per i servizi potrebbero restituire informazioni che consentono di determinare se un tentativo di ripetizione è appropriato e quanto tempo attendere prima del successivo tentativo.
È consigliabile usare il meccanismo di ripetizione predefinito quando è disponibile, a meno che non si disponga di requisiti specifici e ben compresi che rendano più appropriato un comportamento di ripetizione diverso.
Determinare se l'operazione è adatta per riprovare
Eseguire operazioni di ripetizione dei tentativi solo quando gli errori sono temporanei (in genere indicati dalla natura dell'errore) e quando si verifica almeno una certa probabilità che l'operazione abbia esito positivo quando viene ritentata. Non è possibile ripetere le operazioni che tentano un'operazione non valida, ad esempio un aggiornamento del database a un elemento che non esiste o una richiesta a un servizio o a una risorsa che ha subito un errore irreversibile.
In generale, implementare nuovi tentativi solo quando è possibile determinare l'effetto completo di questa operazione e quando le condizioni sono ben comprensibili e possono essere convalidate. In caso contrario, lasciare che il codice chiamante implementi nuovi tentativi. Tenere presente che gli errori restituiti da risorse e servizi esterni al controllo possono evolversi nel tempo e potrebbe essere necessario rivedere la logica di rilevamento degli errori temporanei.
Quando si creano servizi o componenti, è consigliabile implementare codici di errore e messaggi che consentono ai client di determinare se devono ripetere le operazioni non riuscite. In particolare, indicare se il client deve ritentare l'operazione (ad esempio restituendo un valore isTransient ) e suggerire un ritardo appropriato prima del successivo tentativo di ripetizione. Se si compila un servizio Web, è consigliabile restituire errori personalizzati definiti all'interno dei contratti di servizio. Anche se i client generici potrebbero non essere in grado di leggere questi errori, sono utili per la creazione di client personalizzati.
Determinare un numero di tentativi e un intervallo appropriati
Ottimizzare il numero di tentativi e l'intervallo per il tipo di caso d'uso. Se non si riprova abbastanza volte, l'applicazione non può completare l'operazione e probabilmente avrà esito negativo. Se si ritenta un numero eccessivo di tentativi o con un intervallo troppo breve tra tentativi, l'applicazione potrebbe contenere risorse come thread, connessioni e memoria per lunghi periodi, che influiscono negativamente sull'integrità dell'applicazione.
Adattare i valori per l'intervallo di tempo e il numero di tentativi al tipo di operazione. Ad esempio, se l'operazione fa parte di un'interazione dell'utente, l'intervallo deve essere breve e devono essere tentati solo alcuni tentativi. Usando questo approccio, è possibile evitare di rendere gli utenti in attesa di una risposta, che contiene connessioni aperte e può ridurre la disponibilità per altri utenti. Se l'operazione fa parte di un flusso di lavoro a esecuzione prolungata o critica, in cui l'annullamento e il riavvio del processo richiede molto tempo, è opportuno attendere più tempo tra i tentativi e riprovare più volte.
Tenere presente che determinare gli intervalli appropriati tra i tentativi è la parte più difficile della progettazione di una strategia di successo. Le strategie più comuni usano i seguenti tipi di intervallo tra tentativi:
Backoff esponenziale. L'applicazione attende un breve periodo di tempo prima del primo tentativo e quindi aumenta in modo esponenziale il tempo tra ogni tentativo successivo. Ad esempio, potrebbe ritentare l'operazione dopo 3 secondi, 12 secondi, 30 secondi e così via.
Intervalli incrementali. L'applicazione attende un breve periodo di tempo prima del primo tentativo e quindi aumenta in modo incrementale il tempo tra ogni tentativo successivo. Ad esempio, potrebbe ritentare l'operazione dopo 3 secondi, 7 secondi, 13 secondi e così via.
Intervalli regolari. L'applicazione attende lo stesso intervallo di tempo prima di ripetere ogni nuovo tentativo. Ad esempio, potrebbe ritentare l'operazione ogni 3 secondi.
Tentativo immediato. A volte un errore temporaneo è breve, probabilmente causato da un evento come un conflitto di pacchetti di rete o un picco in un componente hardware. In questo caso, ritentare immediatamente l'operazione è appropriato perché potrebbe avere esito positivo se l'errore viene cancellato nel tempo necessario all'applicazione per assemblare e inviare la richiesta successiva. Tuttavia, non dovrebbero mai essere presenti più tentativi immediati. È consigliabile passare a strategie alternative, ad esempio azioni di back-off esponenziale o di fallback, se il tentativo immediato non riesce.
Sequenza casuale. Una delle strategie di ripetizione dei tentativi elencate in precedenza può includere una casualizzazione per impedire che più istanze del client inviino tentativi successivi contemporaneamente. Ad esempio, un'istanza potrebbe ritentare l'operazione dopo 3 secondi, 11 secondi, 28 secondi e così via, mentre un'altra istanza potrebbe ritentare l'operazione dopo 4 secondi, 12 secondi, 26 secondi e così via. La randomizzazione è una tecnica utile che può essere combinata con altre strategie.
Come linea guida generale, usare una strategia di back-off esponenziale per le operazioni in background e usare strategie di ripetizione immediata o a intervalli regolari per le operazioni interattive. In entrambi i casi è necessario scegliere l'intervallo di tempo e il numero di tentativi in modo che la latenza massima per tutti i tentativi non superi i requisiti di latenza end-to-end previsti.
Prendere in considerazione la combinazione di tutti i fattori che contribuiscono al timeout massimo complessivo per un'operazione ritentata. Questi fattori includono il tempo necessario per una connessione non riuscita per produrre una risposta (in genere impostata da un valore di timeout nel client), il ritardo tra i tentativi di ripetizione e il numero massimo di tentativi. Il totale di tutti questi tempi può comportare tempi di funzionamento generali lunghi, soprattutto quando si usa una strategia di ritardo esponenziale in cui l'intervallo tra i tentativi aumenta rapidamente dopo ogni errore. Se un processo deve soddisfare un contratto di servizio specifico, il tempo complessivo dell'operazione, inclusi tutti i timeout e i ritardi, deve essere entro i limiti definiti nel contratto di servizio.
Non implementare strategie di ripetizione eccessivamente aggressive. Si tratta di strategie con intervalli troppo brevi o tentativi troppo frequenti. Possono avere un effetto negativo sulla risorsa o sul servizio di destinazione. Queste strategie potrebbero impedire il ripristino della risorsa o del servizio dallo stato di overload e continueranno a bloccare o rifiutare le richieste. Questo scenario comporta un circolo vizioso, in cui sempre più richieste vengono inviate alla risorsa o al servizio. Di conseguenza, la sua capacità di recupero è ulteriormente ridotta.
Tenere conto del timeout delle operazioni quando si sceglie intervalli di ripetizione dei tentativi per evitare di avviare immediatamente un tentativo successivo( ad esempio, se il periodo di timeout è simile all'intervallo di ripetizione dei tentativi). Valutare anche se è necessario mantenere il periodo totale possibile (il timeout più gli intervalli di ripetizione dei tentativi) al di sotto di un tempo totale specifico. Se un'operazione presenta un timeout insolitamente breve o lungo, il timeout potrebbe influire sulla durata dell'attesa e sulla frequenza con cui ripetere l'operazione.
Usare il tipo dell'eccezione e i dati contenuti o i codici di errore e i messaggi restituiti dal servizio per ottimizzare il numero di tentativi e l'intervallo tra di essi. Ad esempio, alcune eccezioni o codici di errore (ad esempio il codice HTTP 503, Servizio non disponibile, con un'intestazione Retry-After nella risposta) potrebbero indicare per quanto tempo l'errore potrebbe durare o che il servizio non è riuscito e non risponderà ad alcun tentativo successivo.
Evitare antipattern
Nella maggior parte dei casi, evitare implementazioni che includono livelli duplicati di codice di ripetizione dei tentativi. Evitare progettazioni che includono meccanismi di ripetizione dei tentativi a catena o che implementano nuovi tentativi in ogni fase di un'operazione che implica una gerarchia di richieste, a meno che non si disponga di requisiti specifici che richiedono tale operazione. In questi casi eccezionali usare criteri che impediscono un numero eccessivo di tentativi e periodi di attesa e accertarsi di comprendere le conseguenze di questo tipo di progettazione. Si supponga, ad esempio, che un componente effettui una richiesta a un'altra, che quindi accede al servizio di destinazione. Se si implementa un nuovo tentativo con un conteggio di tre su entrambe le chiamate, sono presenti nove tentativi in totale rispetto al servizio. Molti servizi e risorse implementano un meccanismo di ripetizione dei tentativi predefinito. È consigliabile esaminare come disabilitare o modificare questi meccanismi se è necessario implementare nuovi tentativi a un livello superiore.
Non implementare mai un meccanismo a ciclo infinito. In questo modo è probabile che impedisca al servizio o alla risorsa di eseguire il ripristino da situazioni di overload e di causare la limitazione e la rifiuto delle connessioni per continuare per un periodo di tempo più lungo. Usare un numero finito di tentativi o implementare un modello come Interruttore di circuito per consentire al servizio di eseguire il ripristino.
Evitare di eseguire più volte una ripetizione di tentativo immediata.
Evitare di usare un intervallo di ripetizione dei tentativi regolare quando si accede a servizi e risorse in Azure, soprattutto quando si ha un numero elevato di tentativi. L'approccio migliore in questo scenario è una strategia di back-off esponenziale con funzionalità di interruzione del circuito.
Impedire a più istanze dello stesso client o a più istanze di client diversi di inviare nuovi tentativi contemporaneamente. Se questo scenario è probabile che si verifichi, introdurre la casualizzazione negli intervalli di ripetizione dei tentativi.
Testare la strategia e l'implementazione dei tentativi
Testare completamente la strategia di ripetizione dei tentativi nel minor numero possibile di circostanze, soprattutto quando sia l'applicazione che le risorse o i servizi di destinazione usati sono sottoposti a carico estremo. Per controllare il comportamento durante il test, è possibile:
Inserire nel servizio errori temporanei e non temporanei. Ad esempio, inviare richieste non valide o aggiungere il codice che rileva le richieste di test e risponde con diversi tipi di errori. Per esempi che usano TestApi, vedere Test injection degli errori con TestApi e Introduzione a TestApi - Parte 5: API di inserimento degli errori del codice gestito.
Creare un mockup della risorsa o del servizio che restituisce un intervallo di errori restituiti dal servizio reale. Coprire tutti i tipi di errori che la strategia di ripetizione dei tentativi è progettata per rilevare.
Per i servizi personalizzati creati e distribuiti, forzare l'esecuzione di errori temporanei disabilitando temporaneamente o eseguendo l'overload del servizio. Non tentare di eseguire l'overload di risorse condivise o servizi condivisi in Azure.
Per le API basate su HTTP, prendere in considerazione l'uso di una libreria nei test automatizzati per modificare il risultato delle richieste HTTP, aggiungendo tempi di round trip aggiuntivi o modificando la risposta ,ad esempio il codice di stato HTTP, le intestazioni, il corpo o altri fattori. In questo modo è possibile eseguire test deterministici di un subset delle condizioni di errore, per errori temporanei e altri tipi di errori.
Eseguire test simultanei e fattori di carico elevati per garantire che il meccanismo e la strategia di ripetizione dei tentativi funzionino correttamente in queste condizioni. Questi test aiuteranno anche a garantire che il nuovo tentativo non abbia un effetto negativo sul funzionamento del client o causare contaminazione incrociata tra le richieste.
Gestire le configurazioni dei criteri di ripetizione dei tentativi
Un criterio di ripetizione dei tentativi è una combinazione di tutti gli elementi della strategia di ripetizione dei tentativi. Definisce il meccanismo di rilevamento che determina se è probabile che un errore sia temporaneo, il tipo di intervallo da usare (ad esempio, back-off esponenziale regolare e casualizzazione), i valori effettivi dell'intervallo e il numero di tentativi.
Implementare i tentativi in molte posizioni, anche nell'applicazione più semplice e in ogni livello di applicazioni più complesse. Invece di impostare come hardcoded gli elementi di ogni criterio in più posizioni, è consigliabile usare un punto centrale per archiviare tutti i criteri. Ad esempio, archiviare valori come l'intervallo e il numero di tentativi nei file di configurazione dell'applicazione, leggerli in fase di esecuzione e compilare i criteri di ripetizione dei tentativi a livello di codice. In questo modo è più semplice gestire le impostazioni e modificare e ottimizzare i valori per rispondere ai requisiti e agli scenari mutevoli. Tuttavia, progettare il sistema per archiviare i valori anziché rileggere un file di configurazione ogni volta e usare valori predefiniti appropriati se i valori non possono essere ottenuti dalla configurazione.
In un'applicazione azure Servizi cloud prendere in considerazione l'archiviazione dei valori usati per compilare i criteri di ripetizione dei tentativi in fase di esecuzione nel file di configurazione del servizio in modo da poterli modificare senza dover riavviare l'applicazione.
Sfruttare le strategie predefinite o predefinite per i tentativi disponibili nelle API client usate, ma solo quando sono appropriate per lo scenario. Queste strategie sono in genere generiche. In alcuni scenari, potrebbero essere tutti necessari, ma in altri scenari non offrono l'intera gamma di opzioni per soddisfare i requisiti specifici. Per determinare i valori più appropriati, è necessario eseguire test per comprendere in che modo le impostazioni influiscono sull'applicazione.
Registrare e tenere traccia degli errori temporanei e nontransienti
Nell'ambito della strategia di ripetizione dei tentativi, includere la gestione delle eccezioni e altre strumentazioni che registrano i tentativi. Un errore temporaneo occasionale e un nuovo tentativo sono previsti e non indicano un problema. Tuttavia, il numero regolare e crescente di tentativi è spesso un indicatore di un problema che potrebbe causare un errore o che degrada le prestazioni e la disponibilità dell'applicazione.
Registrare gli errori temporanei come voci di avviso anziché come voci di errore in modo che i sistemi di monitoraggio non li rilevino come errori dell'applicazione che potrebbero attivare falsi avvisi.
Prendere in considerazione l'archiviazione di un valore nelle voci di log che indica se i tentativi sono causati dalla limitazione nel servizio o da altri tipi di errori, ad esempio errori di connessione, in modo da poterli distinguere durante l'analisi dei dati. Un aumento del numero di errori di limitazione è spesso indicativo di un problema di progettazione nell'applicazione o della necessità di passare a un servizio premium in grado di offrire hardware dedicato.
Valutare e registrare i tempi complessivi trascorsi per le operazioni che includono un meccanismo di ripetizione dei tentativi. Questa metrica è un buon indicatore dell'effetto complessivo degli errori temporanei nei tempi di risposta dell'utente, nella latenza dei processi e nell'efficienza dei casi d'uso delle applicazioni. Registrare anche il numero di tentativi che si verificano in modo da poter comprendere i fattori che contribuiscono al tempo di risposta.
Valutare la possibilità di implementare un sistema di telemetria e monitoraggio in grado di generare avvisi quando il numero e la frequenza degli errori, il numero medio di tentativi o i tempi complessivi trascorsi prima che le operazioni abbiano esito positivo aumentano.
Gestire le operazioni che non riescono continuamente
Si consideri come gestire le operazioni che continuano a non riuscire a ogni tentativo. Situazioni come questa sono inevitabili.
Anche se una strategia di ripetizione dei tentativi definisce il numero massimo di tentativi di ripetizione di un'operazione, non impedisce all'applicazione di ripetere l'operazione con lo stesso numero di tentativi. Ad esempio, se un servizio di elaborazione degli ordini ha esito negativo con un errore irreversibile che lo attiva in modo permanente, la strategia di ripetizione dei tentativi potrebbe rilevare un timeout di connessione e considerarla un errore temporaneo. Il codice ritenta l'operazione un numero specificato di volte e quindi rinuncia. Tuttavia, quando un altro cliente effettua un ordine, l'operazione viene tentata di nuovo, anche se avrà esito negativo ogni volta.
Per evitare tentativi continui per le operazioni che non riescono continuamente, è consigliabile implementare il modello interruttore. Quando si usa questo modello, se il numero di errori all'interno di un intervallo di tempo specificato supera una soglia, le richieste tornano immediatamente al chiamante come errori e non viene eseguito alcun tentativo di accesso alla risorsa o al servizio non riuscito.
L'applicazione può testare periodicamente il servizio, in modo intermittente e con intervalli di tempo lunghi tra le richieste, per rilevare quando diventa disponibile. Un intervallo appropriato dipende da fattori come la criticità dell'operazione e la natura del servizio. Potrebbe essere qualcosa tra alcuni minuti e diverse ore. Quando il test ha esito positivo, l'applicazione può riprendere le normali operazioni e passare le richieste al servizio appena ripristinato.
Nel frattempo, potrebbe essere possibile eseguire il fallback a un'altra istanza del servizio (forse in un data center o un'applicazione diversa), usare un servizio simile che offre funzionalità compatibili (forse più semplici) o eseguire alcune operazioni alternative in base alla speranza che il servizio sarà presto disponibile. Ad esempio, potrebbe essere opportuno archiviare le richieste per il servizio in una coda o in un archivio dati e riprovare in un secondo momento. In alternativa, potrebbe essere possibile reindirizzare l'utente a un'istanza alternativa dell'applicazione, ridurre le prestazioni dell'applicazione, ma offrire comunque funzionalità accettabili o semplicemente restituire un messaggio all'utente per indicare che l'applicazione non è attualmente disponibile.
Altre considerazioni
Quando si decide sui valori per il numero di tentativi e gli intervalli di ripetizione dei tentativi per un criterio, valutare se l'operazione sul servizio o sulla risorsa fa parte di un'operazione a esecuzione prolungata o a più passaggi. Potrebbe essere difficile o costoso compensare tutti gli altri passaggi operativi che hanno già avuto esito positivo quando si verifica un errore. In questo caso, un intervallo molto lungo e un numero elevato di tentativi potrebbe essere accettabile purché tale strategia non blocchi altre operazioni mantenendo o bloccando risorse scarse.
Valutare se ritentare la stessa operazione potrebbe causare incoerenze nei dati. Se alcune parti di un processo a più passaggi vengono ripetute e le operazioni non sono idempotenti, potrebbero verificarsi incoerenze. Ad esempio, se un'operazione che incrementa un valore viene ripetuta, produce un risultato non valido. La ripetizione di un'operazione che invia un messaggio a una coda potrebbe causare una incoerenza nel consumer di messaggi se il consumer non riesce a rilevare messaggi duplicati. Per evitare questi scenari, progettare ogni passaggio come operazione idempotente. Per altre informazioni, vedere Modelli di Idempotency.
Prendere in considerazione l'ambito delle operazioni che vengono ritentate. Ad esempio, potrebbe essere più semplice implementare il codice di ripetizione dei tentativi a un livello che include diverse operazioni e riprovare a eseguirle tutte in caso di errore. Tuttavia, questa operazione potrebbe causare problemi di idempotenza o operazioni di rollback non necessarie.
Se si sceglie un ambito di ripetizione dei tentativi che include diverse operazioni, tenere conto della latenza totale di tutte quando si determinano gli intervalli di ripetizione dei tentativi, quando si monitorano i tempi trascorsi dell'operazione e prima di generare avvisi per gli errori.
Valutare il modo in cui la strategia di ripetizione dei tentativi potrebbe influire sui vicini e sugli altri tenant in un'applicazione condivisa e quando si usano risorse e servizi condivisi. L'adozione di criteri aggressivi di ripetizione dei tentativi possono causare un numero crescente di errori temporanei si verifichi per gli altri utenti e per le applicazioni che condividono le risorse e i servizi. Analogamente, l'applicazione potrebbe essere interessata dai criteri di ripetizione dei tentativi implementati da altri utenti delle risorse e dei servizi. Per le applicazioni critiche per l'azienda, è possibile usare servizi Premium che non sono condivisi. In questo modo è possibile controllare il carico e la conseguente limitazione di queste risorse e servizi, che possono contribuire a giustificare il costo aggiuntivo.