Il comportamento della vernice su MISS

Question

Considerare questo scenario: La cache di Varnish ha un MISS e il server di backend sta ora rigenerando il contenuto richiesto. Durante il tempo di generazione arriva una seconda richiesta e ottiene anche un MISS. La vernice invia questa richiesta al back-end mentre l'altra richiesta è in sospeso? Cosa succede se migliaia di richieste arrivano tra questa volta. Il server si arresterebbe correttamente? Ogni richiesta renderebbe più lento.

È corretto o è la vernice che "sincronizza" questi scenari per evitare un tale problema?

Grazie in anticipo!

Answer 1

Varnish invia tutte le richieste al back-end. Cioè non accoda altre richieste ed emette solo una richiesta di backend e usa la sua risposta per tutti.

Tuttavia, Varnish dispone di un valore grace option che consente di conservare contenuto scaduto e obsoleto nella cache per questi tipi di situazioni.

Ad esempio si consideri il seguente VCL:

sub vcl_recv { 
    if (req.backend.healthy) { 
    set req.grace = 5m; 
    } else { 
    set req.grace = 24h; 
    } 
} 

sub vcl_fetch { 
    set beresp.grace = 24h; 
} 

Ora, se un back-end è sano (vedi backend polling) e una richiesta si traduce in una MISS, la prima richiesta viene inviata a un backend. Se arriva un'altra richiesta per lo stesso contenuto, ma c'è un elemento nella cache con età < TTL + req.grace (in questo caso 5 minuti), quella richiesta otterrà invece il contenuto "stantio". Ciò accade finché la prima richiesta che ha dato origine a MISS ottiene una risposta dal backend (e la cache è di nuovo recente) o l'età dell'elemento diventa maggiore di TTL + req.grace.

Se il back-end era inattivo (req.backend.healthy == FALSE), il contenuto non aggiornato sarebbe servito fino all'età < TTL + 24 ore.

Si potrebbe anche voler controllare la sezione Saving a request del Varnish book per un esempio più approfondito e un esercizio.

Risolto: carattere senza caratteri <.

fisso di più: C'era un altro escape < personaggio ...

Answer 2

credo (accettato) la risposta di Ketola è sbagliata.

Richieste multiple a Varnish per lo stesso URI sarà essere in coda.

Quindi dipende se il risultato della prima richiesta è memorizzabile nella cache o meno. Se lo è, verrà utilizzato anche per altre richieste (in coda). In caso contrario, tutte le altre richieste in coda verranno inviate al back-end.

Quindi, se si ha un endpoint API lento che si desidera memorizzare nella cache ed è memorizzabile nella cache (per quanto riguarda le regole di Varnish), più richieste raggiungeranno il backend una sola volta per quell'URI.

Answer 3

Non ho i punti o qualsiasi cosa da commentare sulla risposta di @ max_i quindi sto inviando un'altra risposta per verificare la sua invece.

La risposta accettata di Ketola non è completamente sbagliata, forse è solo obsoleta e potrebbe essere vera per le versioni precedenti di Varnish.In particolare questa parte:

Varnish invia tutte le richieste al back-end. Cioè non accoda altre richieste ed emette solo una richiesta di backend e usa la sua risposta per tutti.

Dopo il test in modo indipendente io stesso utilizzando un'installazione standard di vernice 4.1 LTS e Apache 2.4, ho creato un file PHP di base che conteneva la seguente:

<?php sleep(5); echo 'hello world!'; 

poi utilizzato ab per testare il ciclo di richiesta HTTP usando 50 richieste a 5 concorrenti. I risultati hanno mostrato che, mentre Varnish accettava ogni singola connessione, al back-end era stata fatta solo una richiesta, che, come previsto, richiedeva circa 5 secondi per essere risolta. Successivamente, ogni connessione di Varnish ha dovuto attendere quel periodo minimo prima di ricevere una risposta.

Il lato negativo di questo è naturalmente che le richieste dopo il primo sono "in coda" dietro di esso, ma questa è ovviamente una preoccupazione minore rispetto a tutte le 50 richieste che colpiscono il back-end in una volta (o nel caso del mio test , con una concorrenza di 5).