Antipattern: memorizzare nella cache le risposte di errore

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

La memorizzazione nella cache è un processo di archiviazione temporanea dei dati in un'area di archiviazione chiamata cache per riferimento futuro. La memorizzazione dei dati nella cache offre notevoli vantaggi in termini di prestazioni perché:

  • Consente un recupero più rapido dei dati
  • Riduce i tempi di elaborazione evitando la rigenerazione ripetuta dei dati
  • Impedisce alle richieste API di raggiungere i server di backend, riducendo così il sovraccarico sui i server di backend
  • Consente un migliore utilizzo delle risorse di sistema/applicazione
  • Migliora i tempi di risposta delle API

Ogni volta che dobbiamo accedere frequentemente ad alcuni dati che non cambiano troppo spesso, consigliamo vivamente di utilizzare una cache per archiviarli.

Apigee Edge offre la possibilità di archiviare i dati in una cache in fase di runtime per la persistenza e un recupero più rapido. La funzionalità di memorizzazione nella cache è disponibile tramite le policy PopulateCache, LookupCache, InvalidateCache e ResponseCache.

In questa sezione esamineremo la policy ResponseCache. La policy ResponseCache nella piattaforma Apigee Edge consente di memorizzare nella cache le risposte dei server di backend. Se le applicazioni client effettuano ripetutamente richieste alla stessa risorsa di backend e la risorsa viene aggiornata periodicamente, possiamo memorizzare nella cache queste risposte utilizzando questa policy. La policy ResponseCache consente di restituire le risposte memorizzate nella cache e, di conseguenza, evita di inoltrare inutilmente le richieste ai server di backend.

La policy ResponseCache:

  • Riduce il numero di richieste che raggiungono il backend
  • Riduce la larghezza di banda della rete
  • Migliora le prestazioni e i tempi di risposta delle API

Antipattern

Per impostazione predefinita,la policy ResponseCache consente di memorizzare nella cache le risposte HTTP con qualsiasi codice di stato possibile. Ciò significa che è possibile memorizzare nella cache sia le risposte di successo sia quelle di errore.

Ecco un esempio di policy ResponseCache con la configurazione predefinita:

<!-- /antipatterns/examples/1-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServer ResponseCache</DisplayName>
  <CacheKey>
    <Key Fragment ref="request.uri" /></CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
      <TimeoutInSec ref="flow.variable.here">600</TimeoutInSec>
    </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
</ResponseCache>

La policy ResponseCache memorizza nella cache le risposte di errore nella sua configurazione predefinita. Tuttavia, non è consigliabile memorizzare nella cache le risposte di errore senza aver riflettuto attentamente sulle implicazioni negative, perché:

  • Scenario 1: si verificano errori per un periodo di tempo sconosciuto e temporaneo e potremmo continuare a inviare risposte di errore a causa della memorizzazione nella cache anche dopo la risoluzione del problema

    OPPURE

  • Scenario 2: gli errori verranno osservati per un periodo di tempo fisso, dopodiché dovremo modificare il codice per evitare di memorizzare nella cache le risposte una volta risolto il problema

Spieghiamo questo aspetto esaminando questi due scenari in modo più dettagliato.

Scenario 1: errore temporaneo del backend/della risorsa

Supponiamo che l'errore nel server di backend sia dovuto a uno dei seguenti motivi:

  • Un problema di rete temporaneo
  • Il server di backend è estremamente occupato e non è in grado di rispondere alle richieste per un periodo di tempo temporaneo
  • La risorsa di backend richiesta potrebbe essere rimossa/non disponibile per un periodo di tempo temporaneo
  • Il server di backend risponde lentamente a causa di un tempo di elaborazione elevato per un periodo di tempo temporaneo, ecc

In tutti questi casi, gli errori potrebbero verificarsi per un periodo di tempo sconosciuto e poi potremmo iniziare a ricevere risposte di successo. Se memorizziamo nella cache le risposte di errore, potremmo continuare a inviare risposte di errore agli utenti anche se il problema con il server di backend è stato risolto.

Scenario 2: errore prolungato o fisso del backend/della risorsa

Supponiamo di sapere che l'errore nel backend si verifica per un periodo di tempo fisso. Ad esempio, sai che:

  • Una risorsa di backend specifica non sarà disponibile per 1 ora

    OPPURE

  • Il server di backend viene rimosso/non è disponibile per 24 ore a causa di un errore improvviso del sito, problemi di scalabilità, manutenzione, upgrade e così via.

Con queste informazioni, possiamo impostare il tempo di scadenza della cache in modo appropriato nella policy ResponseCache in modo da non memorizzare nella cache le risposte di errore per un periodo di tempo più lungo. Tuttavia, una volta che il server/la risorsa di backend è di nuovo disponibile, dovremo modificare la policy per evitare di memorizzare nella cache le risposte di errore. Questo perché, se si verifica un errore temporaneo/una tantum dal server di backend, memorizzeremo nella cache la risposta e ci ritroveremo con il problema spiegato nello scenario 1 sopra.

Impatto

  • La memorizzazione nella cache delle risposte di errore può causare l'invio di risposte di errore anche dopo la risoluzione del problema nel server di backend
  • Gli utenti potrebbero impegnarsi molto per risolvere la causa di un problema senza sapere che è causato dalla memorizzazione nella cache delle risposte di errore dal server di backend

Best practice

  • Non memorizzare le risposte di errore nella cache delle risposte. Assicurati che l' <ExcludeErrorResponse> elemento sia impostato su true nella policy ResponseCache per impedire la memorizzazione nella cache delle risposte di errore, come mostrato nello snippet di codice riportato di seguito. Con questa configurazione, verranno memorizzate nella cache solo le risposte per i codici di successo predefiniti da 200 a 205 (a meno che i codici di successo non vengano modificati). 
    <!-- /antipatterns/examples/1-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServerResponseCache</DisplayName>
  <CacheKey>
    <KeyFragment ref="request.uri" />
  </CacheKey>
  <Scope>Exclusive</Scope>
  <ExpirySettings>
    <TimeoutinSec ref="flow.variable.here">600</TimeoutinSec>
  </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
  <ExcludeErrorResponse>true</ExcludeErrorResponse>
</ResponseCache>
  • Se devi memorizzare nella cache le risposte di errore per un motivo specifico, puoi determinare la durata massima/esatta per cui verrà osservato l'errore (se possibile):
    • Imposta il tempo di scadenza in modo appropriato per assicurarti di non memorizzare nella cache le risposte di errore per un periodo di tempo superiore a quello in cui è possibile visualizzare l'errore.
    • Utilizza la policy ResponseCache per memorizzare nella cache le risposte di errore senza l' <ExcludeErrorResponse> elemento.

    Esegui questa operazione solo se sei assolutamente certo che l'errore del server di backend non si verifichi per un periodo di tempo breve/temporaneo.

  • Apigee non consiglia di memorizzare nella cache le risposte 5xx dei server di backend.