Entendendo o verniz: ele pode armazenar em cache 10.000 páginas estáticas em um site?

Question

Primeiro, eu uso: APC, W3TC, PHP5, Wordpress 3.8, Apache 2.2 e estou recebendo muitas "falhas de cache"

Ainda não entendo muito bem o verniz. Aqui estão algumas estatísticas que recebi do back-end do Unix a partir de alguns minutos:

client_conn: 3744 client_drop: 0 client_req: 3910 cache_hit: 914 cache_miss: 2347

Mudei minha memória de verniz para 3 GB de RAM (de um total de 8).

É normal que o Varnish armazene apenas páginas que são atingidas com frequência? Então, digamos que você tenha um site com 10.000 páginas, o verniz é capaz de manter todos os que estão no cache ou armazena apenas uma certa quantidade de páginas solicitadas com freqüência?

Então, minha pergunta é como melhorar o verniz para armazenar mais páginas em cache e mantê-las no cache por muito tempo (principalmente páginas estáticas que não precisam ser atualizadas muito)

    

Answer 1

3GB deve ser o suficiente, seriamente. Se você realmente atingiu o limite, você não terá a falta de cache, mas a queda de cache, que é, no seu caso: 0.

Assim, a memória provavelmente não é não o problema.

O uso de memória do verniz é bastante simples, ele usa pouca memória para funcionar, e a maior parte da memória é usada para armazenar objetos, o objeto é sobre suas páginas, então uma página html de 50kb armazenada em cache usará cerca de ~ 50kb em verniz.

CONTUDO, se seu objeto e, portanto, seu hash de objeto associado for diferente, por exemplo, porque existem parâmetros de consulta diferentes (não afetando o contato, mas usados para rastrear, por exemplo), cada objeto será armazenado em cache separadamente.

aqui é o vcl padrão para calcular o hash para o objeto:

sub vcl_hash {
  hash_data(req.url);
  if (req.http.host) {
    hash_data(req.http.host);
  } else {
    hash_data(server.ip);
  }

  return (hash);
}

Como você pode ver, é baseado no URL completo e no host. Existe um querystring-vmod para classificar e / ou remover parâmetros de consulta para aumentar a contagem de acessos.

Isso pode ser um bom começo para verificar se o seu objeto não é considerado diferente pelo verniz (na maioria dos casos é por causa de parâmetros de consulta).

Mas, no seu caso, suspeito que você tenha cookies e / ou cabeçalhos de controle de cache incorretos.

Por padrão, o verniz ignorará todas as solicitações com cookies, aumentando sua contagem de erros de cache.

sub vcl_recv {
  // ...

  if (req.http.Authorization || req.http.Cookie) {
    /* Not cacheable by default */

    return (pass);
  }
}

Se você realmente souber o que está fazendo, poderá remover cookies de solicitações e forçar o cache de seu objeto, mas tenha cuidado, você pode armazenar em cache uma página de administração dessa maneira que será entregue aos convidados.

Por exemplo, você pode definir qual URL deve ser armazenado em cache e definir um Cache-Control: public header, e no seu vcl, detectar um cabeçalho Cache-Control público, remover cookies e cache.

Mas, novamente, tenha cuidado.

EDITAR : Você pode estar interessado neste artigo: Verniz e Wordpress nos documentos de verniz

    

Answer 2

No topo da configuração do Unixy Varnish eu adicionei isso depois de pesquisar várias configurações, talvez algumas delas são redundantes, mas minha taxa de cache HIT é muito melhor agora como 60% e consegui baixar a carga da CPU de 3 para 0.10 - 0,50

backend do wordpress

if (!(req.url ~ "wp-(login|admin)")) {
                unset req.http.cookie;
        }

outros arquivos

  if ( req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?[a-z0-9]+)?$" ) {

        unset req.http.cookie;
  }

cookies

if (req.http.Cookie) {
    set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *__utm.=[^;]+;? *", "");

    if (req.http.Cookie == "") {
        remove req.http.Cookie;
    }
}

purgando

if (req.request == "PURGE") {
return (lookup);
}

Além disso, 3GB é um pouco exagerado, eu posso mudá-lo de volta 1 ou 2GB .. mesmo com 10.000 páginas ou mais, mas vou deixá-lo rodar por 24 horas e ver