O que exatamente é esse número de visitantes de 85.000 / dia? Visitantes únicos, total de acessos HTTP, algo mais?
O verniz deve ser capaz de lidar com milhares de acessos por segundo, com pouca CPU e memória, contanto que as solicitações possam ser atendidas no cache. Especialmente quando Slashdotted, uma vez que a maioria das pessoas estará procurando exatamente o mesmo conteúdo. Isso requer um ajuste fino. É bastante conservador por padrão, já que não sabe muito sobre o conteúdo que passa. Ele faz suas descrições com base nos cabeçalhos que vê e um conjunto de regras simples. Por exemplo, por padrão, o Varnish armazena em cache os objetos por 2 minutos, mas somente se nenhum cookie estiver presente na solicitação, e o TTL do objeto for > 0 e ... etc. especificamente vcl_recv e vcl_fetch ) para determinar a lógica padrão e certifique-se de entendê-la.
Assim, um único cookie do Google Analytics definido no seu domínio faz com que todas as solicitações sejam passadas para o back-end, embora os cookies GA não sejam processados pelo servidor de back-end, mas pelo javascript do Google. Um aplicativo WordPress define todos os tipos de cookies, a maioria dos quais são aplicáveis apenas ao conteúdo dinâmico, que são retornados pelo navegador em todas as solicitações. Se sua página contiver 49 ativos estáticos e 1 página dinâmica, isso significa que nenhum desses ativos estáticos será armazenado em cache porque os pedidos contêm um cookie que você não se importa. Somente o cookie na solicitação dinâmica deve passar. Um erro como esse basicamente desativa o verniz. Além disso, os vários cabeçalhos HTTP de controle de cache (e relacionados) que seu código retorna são importantes. Se o seu aplicativo alegar que o objeto recuperado pelo Varnish do back-end já expirou, por exemplo, com um cabeçalho Expires no passado, o Varnish não armazenará esse objeto em cache.
Em outras palavras, você precisará ajustar seu aplicativo para emitir os cabeçalhos corretos, para que os clientes (tanto o Varnish quanto o navegador) possam armazenar em cache o conteúdo retornado. Qualquer coisa que você não pode corrigir em sua aplicação, você pode substituir no VCL do Varnish.
Por exemplo, aqui está meu código para remover vários cookies de rastreamento do lado do cliente de alcançar o servidor. Isso pertence em vcl_recv :
# Remove tracking cookies. The server doesn't need to see them.
if (req.http.Cookie) {
# Remove has_js and Google Analytics __* cookies.
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_[_a-z]+|has_js|sifrFetch)=[^;]*", "");
# Remove a ";" prefix, if present.
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
# Remove cookie header if empty
if (req.http.Cookie == "") {
remove req.http.Cookie;
}
}
Da mesma forma, eu removo os cookies de entrada para determinados caminhos, para que esses pedidos possam ser armazenados em cache:
if ( req.url ~ "^/cms/cms_files/(?:css|img|js)/" || #CMS1
req.url ~ "^/site_files/(?:css|img|imgc|js|swf|uploads|xml/.+\.xml$)" || #CMS1
req.url ~ "^/(?:images|stylesheets|javascripts|swf|site_files/js_libs|site/image|favicon\.ico$|robots\.txt$)" || #CMS2
( req.http.host ~ "(?:shop\.example\.com|www\.example\.nl)" && #Magento
req.url ~ "^/(?:404|js|media|skin|favicon\.ico$)" ) || #Magento
) {
unset req.http.cookie;
}
Eu uso uma sub-rotina semelhante em vcl_fetch, com unset beresp.http.cookie; , para evitar que o backend defina cookies em caminhos que eu não quero.
Você pode adicionar alguns cabeçalhos de depuração que fornecem informações sobre como o verniz processa solicitações. Veja aqueles com o Firebug e você entenderá muito mais sobre seu aplicativo. Outra boa fonte de informação é o Livro de Vernizes . Por exemplo, consulte: link
A maior parte do nosso conteúdo dinâmico é armazenada em cache por 60s, o que é suficiente para evitar uma debandada. Se você precisar de algum conteúdo individual, mas a maior parte do conteúdo de suas páginas é bastante estática, procure no de Varnish. ESI (side-side-includes) que permite especificar diferentes TTLs de cache para diferentes partes da página.
Agora que você reduziu as solicitações de back-end ao mínimo, otimize essas solicitações. Faça o perfil do seu aplicativo, encontre e corrija problemas.
Você está correto:
MaxClients x (maximum physical memory per Apache process) = (total memory Apache can use)
Isso é memória física, não a memória virtual que você mencionou. Na parte superior, a coluna res mostra a memória física usada por cada processo. Cada processo do Apache cresce para os maiores scripts que o seu site executa. Limite MaxClients ao valor que seu servidor pode manipular. Não faz sentido aceitar solicitações para as quais você não tem recursos. Assim que você começa a trocar, você perdeu. Aumente a quantidade de processos (Servidores) que o Apache preprografa, já que o forking é uma operação pesada que você quer fazer quando já está ocupado. A linha ServerLimit é redundante. Desative o KeepAlive ou configure-o para 1-2 segundos.
Se você servir muitos recursos estáticos, considere trocar de mod_php para PHP-FPM. Isso mantém seu Apache processando peso leve.