No momento, estamos trabalhando com o requisito de que a primeira resposta do servidor da web seja inferior a 200ms no Reino Unido. Atualmente, com 2 servidores web dedicados no balanceador de carga e 1 servidor db, chegamos a 800ms.

O site no momento tem menos de 5 clientes, 2 produtos, 4 categorias, não há interface para o site no momento, é livre de estilos e imagens.

Também está sendo executado no nginx com o Varnish.

Alguém pode me dar algum conselho sobre configurações de servidor web? Por que a nossa está chegando lentamente? O que você pode recomendar para otimizar isso? Precisa ficar 400% mais rápido!

Eu vou morder.

Essa primeira resposta do servidor da web deve chegar a menos de 200 ms no Reino Unido.
No momento, não há interface para o site, ele é livre de estilos e imagens.

Você não alcançará esses números sem a ajuda do verniz ou do FPC (ou de ambos). Eu certamente espero que esse número também não precise incluir conteúdo estático (sempre que você decidir adicioná-lo) - como é quase impossível de alcançar (exceto por ter pouca ou nenhuma imagem / js / css).

Estamos chegando a 800ms.
Também está sendo executado no Nginx com Verniz

Você tem o Varnish configurado errado.

Uma instalação do Varnish configurada corretamente fornecerá <100ms de tempo de carregamento da página (vemos mais perto de <10ms).

De fato, para o Magento, você deve esperar algo assim,

Quando um cliente não está logado ...
Ou seja. Não ter criado uma sessão única (adicionar ao carrinho / lista de desejos, fazer login etc.)

--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
  Uncached    Mage default cache   Partial FPC cache   Total FPC cache   Varnish

Quando um cliente está logado ...
Ou seja. Tendo criado uma sessão única (logado, itens no carrinho etc.). Neste ponto, o verniz provavelmente estará desativado. E se você optou por usar ESIs - dependendo das chamadas reversas, ele pode manter um tempo de carregamento de página semelhante ao cache do FPC (devido às despesas gerais da inicialização) - ou aumentar o tempo de carregamento da página além de ser desanexado.

--1.4s--------0.8s-----------------0.6s--------------
  Uncached    Mage default cache   Total FPC cache   

Não é um caso de ajuste de verniz - é um caso de - "você não está realmente armazenando nada" .

Os arquivos de configuração ideais do servidor Magento

Não há um, bem, não exatamente.

Operamos mais de 400 servidores, todas lojas Magento - de tamanhos e capacidades variados. E é raro que os arquivos de configuração que temos em um - correspondam aos de outro. Isso ocorre porque nem todas as empresas são iguais.

Os gargalos podem se formar devido a vários motivos diferentes:

1. Elevado número de simultaneidade de visitantes, com sessões ativas
2. Vítimas de bots de rastreamento "ruins", gerando carga necessária e inestimável
3. Alta proporção de ocorrências de navegação em camadas
4. Elevado número de consultas de pesquisa
5. Alto volume de transações por hora
6. Modelo mal construído
7. Muitas / lentas / grandes extensões de terceiros
8. Links de entrada desatualizados, levando a alta proporção de 404 ocorrências
9. Capacidade da interface de rede no limite
10. Catálogo grande / complexo (muitos produtos / categorias / atributos)

Portanto, com lojas em todo esse espectro, cada uma tem uma abordagem diferente para obter um desempenho ideal.

Resolver os problemas descritos acima; deliberadamente evitaremos apenas declarar "mais / melhor hardware"

1. Use um FPC além do verniz
2. Filtre / bloqueie bots defeituosos na borda da rede - ou redirecione todas as solicitações para o Varnish, independentemente do estado / URL do cookie
3. Altere a navegação em camadas do estoque para SOLR, torne os filtros de navegação em camadas dependentes
4. Alterar a pesquisa de estoque para SOLR
5. Distribua a carga do MySQL na configuração Master / Slave - faça isso somente quando a carga de navegação garantida for absorvida pelo Varnish / FPC
6. Recrie o modelo
7. Retire-os
8. Monitore os logs de acesso continuamente e reescreva os URLs no Nginx / Varnish antes da entrega. Se estiver fazendo isso no nível do Nginx - verifique se o Varnish está armazenando em cache os redirecionamentos 301/302.
9. Divida o conteúdo estático em uma CDN ou melhore a conectividade
10. Adicione mais hardware (bem, tivemos que dizer isso em algum momento)

Portanto, com isso em mente - você verá que provavelmente não haverá um arquivo de configuração do Nginx, arquivo de configuração do PHP fcgi pool, arquivo de configuração do MySQL ou arquivo de configuração do Varnish que serão os mesmos. Junte isso ao hardware que muda automaticamente; memória disponível, desempenho de E / S (HDD e rede) e CPU - e você descobrirá que existem variações sutis que levam ao ganho de desempenho de 400% que você deseja - mas nenhuma resposta rápida você encontrará facilmente on-line.

Você pode copiar e colar o white paper Magento patrocinado pelo Peer 1 sobre desempenho (não recomendamos); espero que as configurações não excedam a memória disponível, os limites de encadeamento, os estados TCP / IP, a capacidade de E / S e levem a um desempenho menor do que uma configuração básica do Apache / mod_php.

Então vamos continuar.

A pilha de servidores Magento ideal

É mais provável que você se aproxime da realidade. Um bom exemplo para demonstrar isso é mostrar como um Magento OS dedicado está configurado, o MageStack

Pegue os subcomponentes separados e você terá uma lista do software mais ótimo / crítico, quando configurado corretamente , para executar uma loja Magento. Notavelmente:

Firewall, filtro DOS, Balanceador de Carga, Verniz, Nginx, PHP, Redis, Memcached, MySQL

Então, quando você pergunta:

Qual é a melhor configuração do servidor Magento?

Qual é o seu objetivo exatamente?

1. Alta disponibilidade
2. Confiabilidade
3. Simplicidade de administração
4. atuação
5. Escalabilidade

Chega de palestras, como faríamos isso

Para espelhar parcialmente a resposta dada na falha do servidor em uma linha semelhante. Você tem 3 servidores à sua disposição - então, primeiro oriente-os da melhor maneira possível. Evitaremos uma solução altamente disponível, pois está muito além do escopo desta resposta.

Os subcomponentes necessários para uma configuração de vários servidores são:

• Firewall
• Balanceador de carga
• Servidor web
• Servidor MySQL
• Armazenamento comum

Então, vamos propósitos múltiplos de alguns dos sistemas. A conformidade com o PCI-DSS determina uma função para cada servidor. Assim, com 5 funções e 3 servidores - você será violado imediatamente. O MageStack contorna isso usando a virtualização - você pode fazer o mesmo.

Servidor 1: Balanceador de carga + servidor Web
Servidor 2: servidor Web
Servidor 3: servidor de banco de dados

Sem largura de banda de rede de baixa latência e significativa (> 1 Gbps, <125 µs), em vez de ter armazenamento comum - é melhor você simplesmente armazenar o diretório raiz da loja em cada máquina e replicar os dados, em tempo real usando ionotifyou diminuindo usando um crontrabalho. Mais uma vez, evitaremos sistemas de arquivos de rede como NFS ou dispositivos de bloco replicados como Gluster ou DRBD - pois é necessário um grande ajuste e largura de banda de rede decente.

O verniz precisa ficar o mais próximo possível da frente. Mas o Varnish não pode descriptografar o SSL. Então combine-o com um terminador SSL; Nginx, Pound, Stunnel, Stud etc. O balanceador de carga embutido no Varnish não é ótimo - mas seria adequado para uma configuração de 2 servidores.

Nginx + PHP-FPM é bom, mas não beba muito do kool-aid Nginx. Ele terá um desempenho quase idêntico a uma configuração tradicional do Apache / mod_php, aqui estão algumas boas leituras sobre por que não usar o Nginx . O Nginx é bom, muito bom, mas certamente não é um gargalo de uma loja Magento - e dada a sua complexidade e falta de suporte nativo ao Magento. A maioria dos administradores de sistema iniciantes se beneficiaria do uso do Apache / mod_php sobre qualquer outra coisa. Pode parecer uma recomendação arcaica sobre o uso do PHP-FPM - mas nossos testes de desempenho mostraram que o desempenho é apenas 7% mais rápido com a solução Nginx - quando configurado corretamente. O ajuste e a experiência necessários para uma configuração Nginx / PHP-FPM confiável e de alto desempenho são bastante vastos para que ele supere o Apache / mod_php. Qualquer que seja a sua escolha, é a sua chamada.

O servidor de banco de dados é simples, MySQL. Porém, como mencionado anteriormente, se você possui um site com alta conversão, é aconselhável uma configuração Master / Slave. Se você deve seguir essa abordagem, pode ser determinado lendo este artigo .

Em seguida, seu back-end periférico armazena em cache Memcached e Redis. Em lojas menores, armazenar sessões em uma instância do Memcache e o cache de back-end rápido em outra trará bons benefícios de desempenho. Não defendemos o armazenamento das tags de cache em um back-end lento - pois isso causa mais problemas do que gera. Portanto, com uma configuração do Memcached, você terá que perder a marcação de cache . Em vez disso, usamos uma configuração como esta .

O Redis não é nativo do Magento, mas com a extensão de Colin Mollenhour - é uma solução melhor que o Memcache, suporta tags de cache, armazenamento de sessões e até armazenamento persistente de cache - não é tão volátil quanto o Memcache . Mas tem suas desvantagens. Descobrimos em lojas de produção em larga escala (> 500 pedidos / hora,> 30k exclusivos / hora) que o cache (e as tags) podem ser preenchidos muito rapidamente e, uma vez atingido o ponto de saturação, o mecanismo LRU falha um pouco ( apesar das configurações diferentes) e causa um grande gargalo imediato. Portanto, é prudente remover regularmente registros antigos manualmente.

Então, qual hardware deve ser usado para quê?

Servidores Web: CPU mais rápida, a maioria dos núcleos de CPU, proporção de 2 GB de RAM / núcleo de
servidor DB: CPU rápida, I / O de disco mais rápida, a maioria de RAM

Portanto, ao realizar várias finalidades em suas três máquinas, o melhor layout seria:

Servidor 1: Terminador SSL -> Verniz -> Nginx / Apache>
Servidor PHP 2: Nginx / Apache> PHP, Redis, (MySQL Slave)
Servidor 3: MySQL

Quanto à configuração específica de cada aplicativo. Bem, isso depende das suas especificações de hardware, da complexidade da sua loja, do seu tipo e natureza do visitante e do grande volume de visitantes.

Você está em um ótimo caminho com essa configuração de cluster. Eu recomendo adicionar um host de cache dedicado para Redis; selecione um com alto poder de CPU e muita RAM (~ 64 GB).

Aqui está a lista completa de configurações que usei para um cluster LEMP altamente disponível, tolerante a falhas, distribuído e com balanceamento de carga. Ele inclui app/etc/local.xml, a core_config_datamesa, e configurações para o MySQL, php-fpm, nginx, e Redis. Todos executam o Ubuntu 12.04 LTS de 64 bits. As configurações incluem muitas otimizações sem inconvenientes.

luzes

• Usuários administrativos: 46
• Categorias: 2.450 (a maior delas possui 2.400 produtos)
• Entidades do produto: 101.000
• Produtos combinados: 484
• Relações do produto: 54.000
• Em estoque e produtos configuráveis ​​ativados: 10.100
• Blocos CMS: 3.100
• Páginas CMS: 1.400

Tráfego de agosto de 2013:

• 40 milhões de visualizações de página mensais
• 2,3 milhões de visitantes únicos
• 46.000 caixas mensais
• 89% dos visitantes dos EUA

Hosts da Web

Existem 10 hosts atrás de firewalls de hardware redundantes e altamente disponíveis e balanceadores de carga de hardware. A maioria dos ativos estáticos é transferida para uma CDN.

• tempo médio de resposta no site: 282 ms
• Resposta média do CPE: 48 ms
• média de carga: 0,6 a 1,0 (em testes, o desempenho diminui em 35% quando a média de carga atinge ~ 5,0)
• CPU Intel Xeon dupla E3-1230 V2 a 3,30 GHz (4 núcleos cada)
• 32 GB DDR3 1333 MHz RAM

Módulos

• https://github.com/colinmollenhour/Cm_RedisSession
• https://github.com/colinmollenhour/Cm_Cache_Backend_Redis
• https://github.com/aligent/CacheObserver.git --branch = models
• https://github.com/aligent/Lokey_ShippingAdjustments
• https://github.com/aligent/VF_CustomMenu.git --branch = production
• https://github.com/Vinai/customer-activation
• https://github.com/gknoppe-guidance/magento-cachebuster

Hosts de cache

Existem dois hosts executando o Redis em uma configuração mestre-escravo com failover automatizado. Três instâncias Redis (sessões, back-end e FPC) são usadas para aumentar a taxa de transferência e fornecer um ajuste fino dos comportamentos de persistência.

• 3.000 comandos por segundo
• Tempo médio de resposta de 0,7 ms
• carga média de 1,0 a 1,5
• CPU Intel Xeon Quad E5-2620 0 a 2.00GHz (6 núcleos cada)
• 128 GB DDR3 em buffer de 1333 MHz RAM
• Discos mecânicos, RAID 1, controlador de hardware

Hosts de banco de dados

Existem dois hosts executando o MySQL 5.6.11 em uma configuração master-slave com failover quente.

• 1.500 comandos por segundo
• Tempo médio de resposta de 1,1 ms
• carga média de 0,1 (mestre) e 0,4 (escravo)
• CPU Quad Intel Xeon E7- 2860 a 2,27 GHz (10 núcleos cada)
• 128 GB DDR3 em buffer de 1333 MHz RAM
• SSD, RAID 1 + 0, controlador de hardware
• MySQL 5.6.11 com tcmalloc

Outro deve ter uma dica de servidor para o Magento é instalar o PHP 5.4 ou 5.5 com o OPcache . O PHP 5.4 é muito mais rápido que o 5.3 ( http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/ ).

Quero adicionar outra dica importante que melhorou a velocidade da página magento quando não é armazenada em cache pelo verniz e não é ativada por padrão (o tempo de carregamento da página do carrinho foi alterado de 6sc para 1,5sc).

Ative o cache de consulta do mysql no /etc/mysql/my.conf

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

o cache_type habilita, tamanho do cache é o valor usado pelo cache na memória e o limite do cache é o tamanho máximo do resultado da consulta para armazenar em cache

Com nossa configuração atual, estamos recebendo resposta inicial em 400 ms e documento completo em 2 segundos (usando uma conexão padrão de 5 mbps). O tamanho da nossa página inicial é 1mb.

Nossa configuração é baseada na AWS da seguinte maneira: Temos uma instância ec2 com um balanceador de carga conectado a um banco de dados RDS (com failover). Também implementamos o cache de página inteira com um back-end de cache redis para armazenamento em cache e armazenamento de sessão.

Em média, temos de 300 a 400 visitantes por dia, mas com o redis caching ativado, tivemos um uso mínimo de recursos do ec2, mantendo a velocidade e reduzindo os custos.

A razão pela qual temos um balanceador de carga é que o ec2 está configurado para inicializar automaticamente uma nova instância, se houver uma rara chance de ter picos de tráfego com os quais a configuração atual não possa lidar.