Experiência do mundo real em desempenho de escala e ajuste

O site em que estou trabalhando supostamente terá uma enorme taxa de acertos logo após o lançamento . O cliente está falando sobre a possibilidade de cerca de 2500 acessos por segundo ao longo de um dia ou mais.

Ignorando o fato de que essa taxa de acerto é provavelmente o otimismo selvagem do cliente e, além de obter os maiores servidores possíveis, qual é a melhor maneira que o Drupal deve ser configurado para suportar uma grande taxa de acerto.

Eu li Scaling the drupal.org Infrastructure , blog de desempenho Drupal , Best Practices for Scaling Drupal e muitas outras páginas, mas o que estou procurando é uma experiência real de fazer isso, o que funciona, o que não funciona e o que fazer. Espero.

A resposta de Markdorison é basicamente o método aceito para atacar esse problema. Vou levar um pouco mais longe.

Quando você tiver o Pressflow para D6 ou Drupal para D7, o Memcached e o Varnish funcionando bem juntos, precisará codificar o seu arquivo VCL de maneira personalizada . Existem gratuitos disponíveis que dão pontos de partida, mas você sempre precisa brincar com eles.

Para que o Varnish funcione de maneira ideal, inicie-o com -s malloc xG em vez do padrão -s file / path / to / file. Além disso, com o Varnish, os itens estáticos do cache do Varnish podem ser mantidos pelo maior tempo possível.

Se você tiver mais de um servidor Web, remova o ETag do cabeçalho enviado ao Varnish no VCL. Também removo o Expira e simplesmente confio na Idade e na idade máxima nos cabeçalhos para que os navegadores voltem ao site.

A versão 1.5 (a partir de 3 de março de 2011) ainda é a versão mais rápida do módulo Memcached do Drupal.org. Normalmente, implanto-o usando uma única bandeja por servidor para reduzir o tráfego tcp para conexões com várias caixas em grande escala)

Configure o armazenamento em cache em "Desempenho" como externo e defina uma idade máxima que enviará os cabeçalhos corretos para um proxy de armazenamento em cache, como o Varnish.

Se você não conseguir que determinadas páginas sejam armazenadas em cache corretamente no Varnish, verifique as postagens do blog na Web que detalham como inspecionar as solicitações. Aqui está um exemplo de um post que escrevi há algum tempo: O que está impedindo o Varnish e o Drupal Pressflow de armazenar em cache visualizações de páginas de usuários anônimos

Você deve escolher o InnoDB (ou um dos outros nomes de outros provedores como o XtraDB) para MySQL e mover todas as tabelas para ele. Em seguida, confira esta postagem do blog para obter conselhos básicos de ajuste http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

Ter um grande conjunto de buffers é fundamentalmente importante. Ao carregar o teste, o site ative o log de consultas lentas. Você provavelmente deseja capturar consultas com duração superior a 50 ms e, em seguida, ajustá-las e reduzir repetidamente o tempo lento de captura de log até que a maioria das consultas seja executada usando índices e executada rapidamente.

Outros princípios básicos envolvem ter o APC no PHP. Se você optar por CGI rápido, em vez de mod_php, gaste algum tempo tentando tornar o cache da APC compartilhado entre as instâncias php, configurando um bom script de wrapper. Verifique também se o cache da APC está em um arquivo mapeado na memória para extrair todo o bit do PHP.

Eu recomendaria começar com o Pressflow (se estiver usando o Drupal 6), Memcache , Varnish e alguma forma de CDN (Content Distribution Network), como a Akamai. O resultado final deve ser o menor número possível de usuários, atingindo o servidor de origem.

Se você possui partes da página que não conseguem armazenar em cache para usuários não anônimos (itens específicos para esse usuário, "Bem-vindo usuárioX" etc.), você pode explorar opções para preencher essas partes da página, como assíncronas retornos de chamada ou margem inclui.

Se você tiver um grupo menor de usuários internos (como um grupo de editores) que precisem visualizar uma versão não armazenada em cache do site, recomendo expor uma versão não armazenada em cache do site em um URL diferente (protegido por uma VPN ou equivalente, se possível).

2500 ocorrências por segundo em um dia - se, por "ocorrência", você quer dizer "página entregue", isso representa 216 milhões de páginas por dia. Deixe-me dizer uma coisa: você não tem 216 milhões de páginas por dia. Eu amo esses clientes ...

Dito isto, um dado de tráfego bruto não diz nada. Embora os conselhos neste tópico sejam sólidos sobre o Varnish / CDN, se tudo o que você tem é tráfego anônimo, mas se o tráfego foi registrado, você está enfrentando um desafio. Mas antes de gastar uma quantidade absurda de tempo e esforço para resolver um problema, verifique se você tem um problema. 2500 batidas por segundo, o Bing fica menos que isso, você percebe isso, certo?

• Lado do servidor

  • Instale o Varnish para armazenar páginas em cache para usuários anônimos.
  • Instale um sistema de cache persistente (Memcached, APC, Memcache).
  • Use uma CDN como a Akamai para servir arquivos estáticos (JavaScript, CSS, imagens).

• Code Side

  • Use o Pressflow, ele permite que o Varnish sirva a página em cache para usuários anônimos.
  • Limpe a mesa de vigilância do Drupal. Toda vez que um erro de watchdog é registrado, ele consome recursos da CPU no servidor da Web e no servidor de banco de dados. Também aumenta significativamente o tempo de carregamento.
  • Implemente estratégias de cache estático e persistente até que o log de consultas lento seja limpo.
  • Evite erros de PHP que ocorram em loops foreach aninhados a todo custo.
  • Desinstale os módulos não utilizados.
  • Ative o armazenamento em cache para os blocos principais e as visualizações do Drupal.

• Base de dados

  • Verifique se as tabelas estão indexadas corretamente para uma pesquisa mais rápida.
  • Não armazene registros desnecessários, um banco de dados com 100 nós sempre será acessado mais rapidamente que um banco de dados com 3 milhões de nós.

Eu também ouvia este podcast da Lullabot sobre como eles criaram o site do Grammys.com para uma explosão de tráfego ao longo de uma semana. Foi uma explicação bastante educacional.

http://www.lullabot.com/podcasts/podcast-92-grammycom

Embora seja muito difícil prever padrões, se você tiver uma boa idéia dos níveis de tráfego. Carregue teste sua solução. Existem várias opções diferentes e muito não será possível prever até que você tenha tráfego ao vivo, mas se você carregar o teste o máximo possível, pelo menos, terá um grau razoável de confiança de que sua configuração pode lidar com o tráfego.

Toda a sintonia do mundo não ajudará se você não testá-lo primeiro.

Esta foi uma apresentação na DC SF sobre como o economista fez isso. http://sf2010.drupal.org/conference/sessions/performance-testing-economist-online-using-grinder

Para sites de alto tráfego, você deve usar vários servidores e balanceador de carga ou simplesmente CDN. Também é muito importante armazenar em cache o máximo possível para minimizar a carga nos servidores da web.

O uso da CDN (Content Delivery Network ) ajuda a distribuir os recursos por vários domínios (compartilhamento de domínio), o que reduz a carga no servidor da web.

O uso da CDN ajuda no cache distribuído e na aceleração remota, também ajuda a mitigar os ataques DDoS , devido a vários pontos de extremidade. Ajuda na segurança, porque o conteúdo em cache é mais difícil de explorar.

Fornecedores de exemplo: Rapidamente , Rackspace , Akamai , Azure, CloudFlare, Amazon, MaxCDN, Verizon.

Aqui estão mais algumas sugestões:

• Com a CDN, use domínios sem cookies para que os componentes estáticos sejam armazenados em cache (como sstatic.net ). Como alguns proxies podem se recusar a armazenar em cache os componentes solicitados com cookies.
• Aqueça seus caches após limpá-los (usando wget, Cache Warmer , Drush ECL ).
• Use o monitoramento de desempenho (por exemplo, New Relic ou Yottaa, que possui integração com o Drupal).
• Use a ferramenta de monitoramento para o seu site (por exemplo, Nagios).
• Instale o módulo de integração do verniz e do verniz HTTP Accelerator e configure-o .
• Verniz + Authcache: verifique este exemplo de VCL para obter o arquivo de configuração do Authcache Varnish.
• Considere Pound ou NGINX na frente do verniz. Veja: Por que Pound é incrível na frente de verniz .
• O NGINX pode funcionar como proxy reverso e balanceador de carga, para substituir Pound e Varnish.
• Considere uma versão comercial do Varnish ou NGINX para utilizar recursos não disponíveis na versão de código aberto da "comunidade".
• Considere o loadbalancer / cache do hardware para substituir o verniz e a libra (por exemplo, BIG-IP F5 ).
• Use ferramentas como abJMeter para TTFB , teste de carga e estresse em seu aplicativo da web.

Portanto, sua arquitetura da web, do ponto de vista do usuário, pode se parecer com:

1. Usuário (armazenamento em cache do navegador local).
2. NGINX ou Pound + Varnish (balanceador de carga, proxy reverso como acelerador HTTP).
3. Apache (servidor web).
4. PHP-FPM (PHP FastCGI Process Manager).
5. MariaDB (banco de dados).

Para sugestões de otimização do Drupal, verifique: Como você melhora o desempenho do Drupal?

Habilite duas extensões:

• Zend OPcache
• wincache

Seu desempenho funcionará melhor.

Se você deseja alterar o Zend OPcache e o Wincache no Microsoft Azure, primeiro crie um nome de pasta ' ini' em ' D:\home\site\'. Além disso, crie 2 arquivos ' .user.ini' e ' settings.ini'

Adicione a seguinte configuração em cada arquivo:

.user.ini

[PHP]
post_max_size = 32M
memory_limit = 512M
zend.enable_gc = On
upload_max_filesize = 32M
opcache.enable=1

setting.ini

wincache.ocenabled = 1
wincache.ocachesize = 255

Além disso, adicione uma configuração de aplicativo ao seu aplicativo da Web com a chave PHP_INI_SCAN_DIR e o valor d:\home\site\ini

Após alterar o PHP_INI_SYSTEM, reinicie seu aplicativo da web. Se quiser saber mais sobre a configuração de twigging, consulte a documentação da Microsoft .

Após a configuração acima, meu site Drupal (Drupal 8.3) é carregado em 3 segundos.

Você também pode examinar a redistribuição da carga em vários servidores com o auxílio de uma solução de balanceamento de carga baseada em DNS ou de software / hardware. Isso também prejudicaria a tolerância a falhas.