Valori di timeout HTTP POST sensibili da utilizzare per l'invio a livello di codice di richieste?

Question

Quando si invia a livello di codice richieste POST HTTP, quali valori di timeout sarebbero sensati?

Nel mio caso, sto cercando di impostare valori di timeout "sensibili" quando si effettuano richieste POST in PHP, tuttavia questo vale per qualsiasi lingua.

Devo essere in grado di inviare una serie di richieste, ciascuna a un URL specificato dall'utente. Se devo elaborare le richieste in modo consecutivo anziché simultaneamente, vorrei specificare un tempo ragionevole oltre il quale si ritiene che una richiesta sia scaduta.

PHP's timeout socket predefinito è di 60 secondi. Sembra un tempo inutilmente lungo prima di decidere che una richiesta non sarà completata.

Trattandosi di richieste POST che devono essere completate rapidamente, non è necessario recuperare e restituire dati come con una richiesta GET.

Dovremmo essere in grado di supporre, il più delle volte , che la mancata emissione di una risposta a una richiesta entro X secondi significa che è improbabile che l'host emetta una risposta entro un tempo ragionevole per valori di X significativamente inferiore a 60.

Sicuramente gli host impiegano raramente più di 60 secondi per rispondere a una semplice richiesta POST. Raramente impiegano più di 10 secondi? 5 secondi?

Quali potrebbero essere i valori sensibili per X in pratica? Le giustificazioni che accompagnano i suggerimenti sarebbero estremamente utili.

Answer 1

Consiglierei di impostare un test, poiché ci sono troppi fattori coinvolti per dare un valore che sarà sempre sensato.

Una richiesta POST invia i dati da elaborare. Quanto tempo impiega l'elaborazione? Questo sarà specifico per applicazione / dati.

Dov'è l'host? L'utente sta fornendo l'URL, quindi sarà sconosciuto. Non possiamo sapere com'è il traffico tra l'applicazione e l'host. Non siamo in grado di conoscere il carico del server dell'host.

In sostanza, non esiste un timeout sensibile universale. Devi usare il tuo miglior giudizio in base alle tue esigenze specifiche. Imposta un test e usalo per determinare i tuoi limiti.

Answer 2

La maggior parte delle librerie ha un timeout di connessione e un timeout di lettura. Cioè, il timeout tra il tentativo di connettersi al server remoto e il timeout dopo l'invio della richiesta, che dovrebbero attendere una risposta.

Se si tratta di un servizio Web locale, impostarei il timeout di connessione basso, 1 secondo o meno se la tua libreria lo supporta. Se il servizio remoto a cui ti stai connettendo non è disponibile IMHO è meglio restituire immediatamente una risposta all'utente, piuttosto che consentire a tutti i thread di lavoro di bloccare quel servizio remoto, causando altri errori a monte.

Per quanto riguarda il timeout di lettura, è più complicato, è necessario che sia basso, quindi non esaurire il pool di lavoratori che stanno aspettando il ritorno del servizio remoto, ma non lo si desidera così basso che chiude la connessione prima di leggere una risposta. Questo è qualcosa che dovrai testare, quindi monitorare come metrica quando il tuo sistema è in produzione.