Configura vernice

Cache vernice è un acceleratore di applicazioni web open-source (noto anche come Acceleratore HTTP o caching proxy inverso HTTP). La vernice memorizza (o memorizza in cache) file o frammenti di file in memoria, il che consente a Vernice di ridurre il tempo di risposta e il consumo di larghezza di banda della rete su richieste equivalenti future. A differenza dei server web come Apache e Nginx, Varnish è stato progettato per essere usato esclusivamente con il protocollo HTTP.

Requisiti di sistema elenca le versioni supportate di vernice.

WARNING
Noi consiglia vivamente usa vernice per la produzione. Il caching a pagina intera incorporato, al file system o database- è molto più lento di Varnish, ed è progettato per accelerare il traffico HTTP.

Per ulteriori informazioni sulla vernice, consulta:

Diagramma topologico della vernice

La figura seguente mostra una vista di base della vernice nella topologia Commerce.

Diagramma di vernice di base

Nella figura precedente, le richieste HTTP degli utenti su Internet generano numerose richieste di CSS, HTML, JavaScript e immagini (collettivamente denominate risorse). Varnish siede davanti al server web e invia queste richieste al server web.

Quando il server web restituisce le risorse, le risorse memorizzabili in cache vengono memorizzate in vernice. Eventuali richieste successive per tali risorse vengono soddisfatte da Varish (ovvero, le richieste non raggiungono il server web). La vernice restituisce il contenuto memorizzato nella cache in modo estremamente rapido. I risultati sono tempi di risposta più rapidi per restituire il contenuto agli utenti e un numero ridotto di richieste che devono essere soddisfatte da Commerce.

Le risorse memorizzate nella cache da Varish scadono a un intervallo configurabile o vengono sostituite da versioni più recenti delle stesse risorse. È inoltre possibile cancellare la cache manualmente utilizzando Admin o magento cache:clean comando.

Panoramica del processo

In questo argomento viene illustrato come installare inizialmente Vernice con un set minimo di parametri e verificare che funzioni. Esportare quindi una configurazione Vernice dall'amministratore Commerce e testarla nuovamente.

Il processo può essere riassunto come segue:

  1. Installa Vernice e testa accedendo a qualsiasi pagina di Commerce per vedere se ricevi intestazioni di risposta HTTP che indicano che Vernice funziona.

  2. Installa il software Commerce e utilizza l’Amministratore per creare un file di configurazione per Vernice.

  3. Sostituisci il file di configurazione vernice esistente con quello generato dall'amministratore.

  4. Prova di nuovo tutto.

    Se non c’è nulla nel tuo <magento_root>/var/page_cache directory, la configurazione di Varnish con Commerce è stata completata.

NOTE
  • Ad eccezione dei casi indicati, è necessario immettere tutti i comandi descritti in questo argomento come utente con root privilegi.

  • Questo argomento è stato scritto per Varnish su CentOS e Apache 2.4. Se si imposta Vernice in un ambiente diverso, alcuni comandi potrebbero essere diversi. Per ulteriori informazioni, consulta la documentazione sulle vernici.

Problemi noti

Conosciamo i seguenti problemi di vernice:

  • La vernice non supporta SSL

    In alternativa, utilizza la terminazione SSL o un proxy di terminazione SSL.

  • Se si elimina manualmente il contenuto del <magento_root>/var/cache directory, è necessario riavviare Varnish.

  • Possibile errore durante l’installazione di Commerce:

    code language-terminal
    Error 503 Service Unavailable
    Service Unavailable
    XID: 303394517
    Varnish cache server
    

    Se si verifica questo errore, modificare default.vcl e aggiungi un timeout al backend strofa come segue:

    code language-conf
    backend default {
        .host = "127.0.0.1";
        .port = "8080";
        .first_byte_timeout = 600s;
    }
    

Panoramica del caching di Varnish

Il caching delle vernici funziona con Commerce utilizzando:

  • nginx.conf.sample dall’archivio GitHub Magento 2
  • .htaccess file di configurazione distribuito per Apache fornito con Commerce
  • default.vcl per la vernice generata utilizzando Amministratore
INFO
In questo argomento vengono illustrate solo le opzioni predefinite dell'elenco precedente. Esistono molti altri modi per configurare il caching in scenari complessi (ad esempio, utilizzando una rete per la distribuzione di contenuti); tali metodi vanno oltre l’ambito di questa guida.

Alla prima richiesta del browser, le risorse memorizzabili in cache vengono consegnate al browser client da Microsoft e memorizzate nella cache del browser.

Inoltre, per le risorse statiche viene utilizzato un tag di entità (ETag). ETag consente di determinare quando i file statici cambiano sul server. Di conseguenza, le risorse statiche vengono inviate al client quando cambiano sul server, su nuova richiesta di un browser o quando il client aggiorna la cache del browser, in genere premendo F5 o Ctrl+F5.

Ulteriori dettagli sono forniti nelle sezioni seguenti.

Memorizzazione in cache per richiesta browser

Questa sezione utilizza un controllo browser per mostrare come le risorse vengono consegnate al browser nella prima richiesta e successivamente caricate dalla cache locale del browser.

Prima richiesta browser

nginx.conf.sample e .htaccess fornisce opzioni per il caching client. Quando la prima richiesta viene effettuata da un browser per un oggetto memorizzabile in cache, vernice lo consegna al client.

Nella figura seguente viene illustrato un esempio relativo all'utilizzo di un controllo browser:

La prima volta che viene effettuata una richiesta per un oggetto memorizzabile in cache, Varnish lo consegna al browser

L'esempio precedente mostra una richiesta per la pagina principale storefront (m2_ce_my). Le risorse CSS e JavaScript sono memorizzate nella cache del browser client.

NOTE
La maggior parte delle risorse statiche ha un codice di stato HTTP 200 (OK), che indica che la risorsa è stata recuperata dal server.

Seconda richiesta browser

Se lo stesso browser richiede nuovamente la stessa pagina, queste risorse vengono distribuite dalla cache del browser locale, come illustrato nella figura seguente.

Alla successiva richiesta dello stesso oggetto, le risorse vengono caricate dalla cache del browser locale

Nota la differenza di tempo di risposta tra la prima e la seconda richiesta. Anche in questo caso, le risorse statiche hanno un codice di risposta 200 (OK) perché vengono consegnate dalla cache locale per la prima volta.

Utilizzo di Etag in Commerce

L’esempio seguente mostra le intestazioni di risposta per una particolare risorsa statica.

ETag consente di determinare più facilmente se una risorsa statica è stata modificata o meno

calendar.css dispone di un’intestazione di risposta ETag, il che significa che il file CSS sul browser client può essere confrontato con quello sul server.

Inoltre, le risorse statiche vengono restituite con un codice di stato HTTP 304 (Non modificato), come illustrato nella figura seguente.

Il codice di risposta HTTP 304 (Non modificato) indica che la risorsa statica nella cache locale è la stessa del server

Il codice di stato 304 si verifica perché l’utente ha invalidato la cache locale e il contenuto sul server non è cambiato. A causa del codice di stato 304, la risorsa statica contenuto non viene trasferito; solo le intestazioni HTTP vengono scaricate nel browser.

Se il contenuto cambia sul server, il client scarica la risorsa statica con un codice di stato HTTP 200 (OK) e un nuovo ETag.

recommendation-more-help
386822bd-e32c-40a8-81c2-ed90ad1e198c