Best practice per la configurazione del timeout I/O

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X.
informazioni

Le richieste API effettuate dalle applicazioni client passano attraverso vari componenti in Apigee Edge prima di raggiungere i servizi di backend. La maggior parte delle applicazioni client si aspetta che le risposte a queste richieste vengano ricevute in modo tempestivo.

Per ottenere risposte tempestive, i valori di timeout I/O vengono impostati in ciascuno dei componenti attraverso i quali passano le richieste API. Se uno dei componenti del flusso richiede più tempo rispetto al componente precedente, il componente precedente scade e risponde con errori di timeout del gateway 504.

Durante la configurazione del timeout, i valori devono essere configurati in ciascuno dei componenti con la massima cura, altrimenti potrebbero verificarsi errori di timeout del gateway 504.

Questo documento descrive le best practice per la configurazione del timeout I/O su vari componenti attraverso i quali le richieste API passano in Apigee Edge.

Best practice per la configurazione del timeout I/O

Considera le seguenti best practice quando configuri il timeout I/O:

  • Primo componente: utilizza sempre il timeout più alto sul primo componente nel flusso di richiesta API, ovvero l'applicazione client in Apigee Edge.
  • Ultimo componente: usa sempre il timeout più basso sull'ultimo componente nel flusso di richiesta API, ovvero il servizio di backend in Apigee Edge.
  • Tra i componenti: assicurati che esista una differenza di almeno 2-3 secondi nel valore di timeout configurato in ogni componente tra il primo e l'ultimo componente del flusso.
  • Router: è sempre buona norma configurare (modificare) il valore di timeout I/O per un host virtuale specifico, anziché configurarlo sul router. Ciò garantisce che il nuovo valore di timeout influisca solo sui proxy API che utilizzano l'host virtuale specifico e non su tutti i proxy API gestiti dal router.

    Configura (modifica) il timeout I/O sul router solo quando sei assolutamente sicuro che il nuovo valore di timeout I/O sia obbligatorio o applicabile per tutti i proxy API in esecuzione sul router.

  • Processore di messaggi: è sempre opportuno configurare (modificare) il valore di timeout I/O per un proxy API specifico, anziché configurarlo sul processore di messaggi. Ciò garantisce che il nuovo valore di timeout influisca solo sul proxy API specifico e non su tutti i proxy API forniti dal processore di messaggi.

    Configura (modifica) il timeout I/O sul processore di messaggi solo quando sei assolutamente sicuro che il nuovo valore di timeout I/O sia obbligatorio o applicabile per tutti i proxy API in esecuzione sul processore di messaggi.

Scenari di esempio

Gli scenari riportati in questa sezione possono aiutarti a capire come impostare correttamente i valori di timeout I/O.

Scenario 1: richieste ad Apigee Edge direttamente dalle applicazioni client

Questa sezione descrive le best practice da seguire per la configurazione dei valori di timeout in una configurazione di Apigee Edge in cui non sono presenti componenti intermedi tra l'applicazione client e Apigee Edge e tra Apigee Edge e il server di backend.

Configurazione di Apigee di esempio senza componenti intermedi

Flusso che parte dal client e va al router, quindi al processore di messaggi e quindi al server di backend

Se Apigee Edge è configurato come mostrato nel diagramma sopra, senza componenti intermedi, utilizza le seguenti best practice:

  1. L'applicazione client è il primo componente del flusso. Il valore del timeout massimo deve essere impostato sul client.
  2. Il server di backend è l'ultimo componente del flusso. Il valore timeout minimo deve essere impostato sul server di backend.
  3. Configura i valori di timeout su ciascuno dei componenti nel seguente ordine:

    Configura il timeout sul client, quindi il router, il processore di messaggi e il server di backend

    L'esempio seguente mostra i valori di timeout impostati sui vari componenti in base alle linee guida sopra riportate per evitare problemi:

    Configura il timeout sul client a 60 secondi, quindi il router a 57 secondi, il processore di messaggi a 55 secondi e il server di backend a 52 secondi

Scenario 2: richieste ad Apigee Edge da applicazioni client tramite componenti intermedi

Questa sezione descrive le best practice da seguire per la configurazione dei valori di timeout in una configurazione di Apigee Edge in cui sono presenti uno o più componenti intermedi tra l'applicazione client e Apigee Edge e anche tra Apigee Edge e il server di backend.

I componenti intermedi possono essere un bilanciatore del carico, una rete CDN (Content Delivery Network) (CDN), NGINX e così via.

Esempio di configurazione di Apigee con un componente intermedio tra il client e Apigee Edge e tra Apigee Edge e il server di backend

Flusso che parte dal client e va al componente intermedio 1, quindi al router e quindi al processore di messaggi, quindi al componente intermedio 2 e al server di backend.

Se Apigee Edge è configurato come mostrato nel diagramma precedente, con uno o più componenti intermedi, utilizza le seguenti best practice:

  1. L'applicazione client è il primo componente del flusso. Sul client deve essere impostato il valore di timeout più alto.
  2. Il server di backend è l'ultimo componente del flusso. Il valore timeout più basso deve essere impostato sul server di backend.
  3. Configura i valori di timeout su ciascuno dei componenti, inclusi i componenti intermedi, nel seguente ordine:

    Configura il timeout sul client, quindi il componente intermedio 1, il router, il processore di messaggi, il componente intermedio 2 e il server di backend

    L'esempio seguente mostra i valori di timeout impostati sui vari componenti in base alle linee guida sopra riportate per evitare problemi:

    Configura il timeout sul client a 63 secondi, quindi il componente intermedio 1 a 60 secondi, il router a 57 secondi, il server di messaggistica a 55 secondi, il componente intermedio 2 a 52 secondi, il server di backend a 59 secondi