Calcoli un piano di backoff esponenziale per i nuovi tentativi
Questo calcolatore di backoff esponenziale trasforma quattro impostazioni di ripetizione in un elenco preciso di ritardi.
Esegui gratis nel browser
Indichi l’attesa prima del primo nuovo tentativo, il moltiplicatore di crescita, il ritardo massimo consentito e il numero di tentativi. Il risultato mostra l’attesa precedente a ogni ripetizione nella stessa unità di tempo fornita. È utile per verificare configurazioni, documentare il comportamento dei client, confrontare criteri e individuare finestre di recupero troppo lunghe prima della produzione.
Definisca la politica con un’unità coerente
Parta dal ritardo base, cioè dall’attesa prima del primo nuovo tentativo. Scelga un’unità compatibile con il sistema configurato, per esempio millisecondi o secondi, e usi la stessa unità per il ritardo massimo. Il calcolatore non ne impone una, perché il backoff esponenziale segue la medesima aritmetica in qualunque unità. Il moltiplicatore controlla la velocità di crescita del ritardo non ancora limitato. Un valore pari a due raddoppia ogni attesa successiva, mentre uno mantiene un intervallo costante. Il numero di tentativi indica le ripetizioni e non comprende l’operazione iniziale: inserendo cinque, Lei ottiene cinque record numerati da uno a cinque. Esplicitare questa distinzione evita un frequente errore di conteggio nei manuali operativi e nelle revisioni. Il ritardo base deve essere positivo, il moltiplicatore almeno uno, il massimo positivo e il numero di tentativi un intero compreso tra uno e mille. Questi vincoli rendono significativo il piano e ne limitano le dimensioni. Se l’applicazione usa millisecondi, etichetti di conseguenza i risultati copiati, così nessuno li interpreterà in seguito come secondi.
Comprenda la crescita e il limite massimo
Per il tentativo n, il ritardo senza limite è il ritardo base moltiplicato per il moltiplicatore elevato a n meno uno. Il valore restituito è il minore tra tale risultato e il ritardo massimo. Per esempio, una base di 250, un moltiplicatore di due e un massimo di 2,000 producono 250, 500, 1,000, 2,000 e poi ancora 2,000 per tutti i tentativi successivi. Il limite si applica anche quando è inferiore alla base: con base dieci e massimo tre, il risultato è tre fin dal primo tentativo. Questo comportamento rispetta un tetto rigoroso e rende visibili le configurazioni insolite anziché modificarle in silenzio. L’implementazione procede iterativamente, senza affidarsi a una potenza illimitata, e interrompe la crescita non appena raggiunge il tetto. In questo modo anche moltiplicatori enormi restano deterministici senza introdurre un valore infinito nel JSON. Il piano non include variazioni casuali. La scelta è intenzionale: espone la politica deterministica che il jitter modificherebbe e rende il risultato adatto a test, documentazione e confronti. Aggiunga separatamente il jitter secondo le regole precise della Sua libreria client.
Applichi il piano senza provocare una tempesta di tentativi
Usi il risultato per esaminare l’intervallo temporale prima di distribuire una politica. Un ritardo base breve può sembrare innocuo, ma un moltiplicatore alto porta rapidamente i tentativi successivi al tetto e può allungare molto il recupero complessivo. Confronti ogni attesa con i timeout delle richieste, i periodi di visibilità delle code, il ripristino dei limiti di frequenza e la durata massima tollerabile dagli utenti. Il calcolatore riporta le attese prima dei nuovi tentativi; non comprende la durata della richiesta originale né il lavoro svolto durante ciascun tentativo fallito. Sommi tali durate separatamente per stimare il peggiore scenario completo. Nei sistemi distribuiti, piani deterministici possono indurre molti client a riprovare contemporaneamente dopo un guasto comune. I client di produzione aggiungono spesso un jitter limitato per distribuire il carico, conservando il piano calcolato come tetto o valore centrale. Questa capacità non esegue richieste, non attende, non contatta servizi e non decide se un errore sia ripetibile. Calcola soltanto il piano aritmetico, senza rete né stato memorizzato. L’esecuzione nel browser è gratuita; l’automazione tramite API costa $0.002 per richiesta.
Casi d'uso
Verifichi le impostazioni di un SDK
Trasformi i parametri proposti in attese concrete prima di approvare la configurazione di un client.
Documenti i tempi di recupero
Inserisca in una procedura un piano esatto per tentativo senza calcolare manualmente le potenze.
Provi i generatori di configurazione
Confronti automaticamente le politiche generate con piani deterministici e limitati.
Domande frequenti
Quale unità di tempo usa il calcolatore?
Va bene qualsiasi unità coerente. Se base_delay è in millisecondi, anche ogni ritardo restituito e max_delay lo sono.
Il numero di tentativi include la richiesta iniziale?
No. Conta le ripetizioni dopo la richiesta iniziale e il piano contiene esattamente quel numero di elementi.
Il massimo si applica prima del primo nuovo tentativo?
Sì. Ogni ritardo è limitato, incluso il primo; max_delay può quindi essere inferiore a base_delay.
Il risultato include il jitter?
No. Calcola il piano esponenziale deterministico. Applichi il jitter a parte secondo le regole del Suo client.
Che cosa accade quando viene raggiunto il limite?
Il ritardo resta pari a max_delay per quel tentativo e per tutti i successivi del piano richiesto.
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo stack
curl -X POST https://api.kit.forhosting.com/dev2/retry-backoff-schedule \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"base_delay":250,"multiplier":2,"max_delay":8000,"attempts":6}'const res = await fetch("https://api.kit.forhosting.com/dev2/retry-backoff-schedule", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"base_delay": 250,
"multiplier": 2,
"max_delay": 8000,
"attempts": 6
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev2/retry-backoff-schedule",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"base_delay": 250,
"multiplier": 2,
"max_delay": 8000,
"attempts": 6
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/retry-backoff-schedule", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"base_delay":250,"multiplier":2,"max_delay":8000,"attempts":6}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"base_delay":250,"multiplier":2,"max_delay":8000,"attempts":6}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/retry-backoff-schedule", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Esempio di richiesta
{
"base_delay": 250,
"multiplier": 2,
"max_delay": 8000,
"attempts": 6
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.retry_backoff_schedule",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Limiti
max_attempts | 1000 |
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |