Qual servidor MySQL fornece um melhor desempenho para o Magento

O que você usa como servidor MySQL para Magento?

• MySQL (Oracle)
• Percona
• outros (MariaDB)

A Percona fornece um conjunto de melhorias para o armazenamento do InnoDB usado intensamente pelo Magento, mas essas melhorias fazem a diferença ao executar uma loja Magento.

Como você melhora o desempenho (abordagens gerais sobre arquitetura, informações não específicas sobre como definir variáveis ​​específicas, como innodb_flush_log_at_trx_commit=2assim por diante). Eu sei que o NBS tentou replicação mestre-mestre, mas isso não é estável.

Eu encontrei alguns problemas com uma replicação mestre-escravo com leituras redirecionadas para o escravo, porque houve alguns atrasos na replicação de dados.

Saindo do MySQL, tanto quanto possível? (pesquise solr e assim por diante).

Você está entrando em um mundo amplo e amplo de otimização aqui e certamente não existe uma abordagem única para todos.

Definir desempenho

Você quer dizer o tempo de carregamento da página para um único usuário ou a capacidade geral / simultaneidade total? Os dois são muito distintos - e não estritamente relacionados. É perfeitamente possível ter uma loja rápida com capacidade limitada; ou uma loja lenta com muita capacidade.

Portanto, ao abordar qualquer tipo de desempenho:

1. Tempo de carregamento da página percebida por um único usuário
2. Capacidade total / simultaneidade

Você precisa enfrentar cada um de forma independente com suas próprias soluções - especialmente porque cada um tem seus próprios gargalos.

Vamos supor que você esteja com um host competente que já tenha configurado os outros aspectos do seu servidor de maneira ideal para sua loja.

Tempo de carregamento da página percebida por um único usuário

O MySQL é o gargalo
não. Não diretamente. É tudo sobre latência, na maioria dos casos ao testar o tempo de carregamento da página - apenas os caches serão atingidos. Portanto, a chave aqui é minimizar a latência.

• Ajuste os tamanhos de cache do MySQL adequadamente (não há resposta certa, ajustamos as configurações de maneira totalmente diferente, mensalmente, por loja)
• Reduza a latência da rede. Para quadros de 64 bytes; 51,2µs para 10Mbps, 5,12µs para 100Mbps e 4,096µs para 1Gbps. Isso proporciona uma melhoria de 20% apenas com a transição de 100 Mbps para 1 Gbps. ^s1
• Aumente a capacidade da rede. Você ficaria surpreso com os muitos megabytes por segundo trocados entre um servidor Web e DB, geralmente acima de 10 MB / s - portanto, é necessário um mínimo de 100 Mb / s ^s1 . Ou apenas mova o servidor DB localmente.
• Usando SOLR. Às vezes, os mecanismos externos são mais adequados, o SOLR certamente é mais rápido para catálogos MAIORES (e eu enfatizaria, catálogos maiores ). Mesmo o SOLR não sintonizado produzirá navegação em camadas e resultados de pesquisa mais rapidamente do que o MySQL.

Mas essas alterações terão um impacto tão fracionário no tempo de carregamento da página - onde o gargalo está realmente em outro lugar.

• Ajuste o aplicativo. O Magento tem alguns bugs bastante grandes com a maneira como cria coleções e as armazena em cache; deparamos com vários problemas importantes de código principal que podem prejudicar o desempenho. Em alguns casos, a simples remoção da exibição da contagem de produtos nos resultados da navegação em camadas reduziu em 2 segundos o carregamento de uma grande coleção.
• Revise os logs lentos do MySQL. Verifique as consultas lentas e adicione índices conforme necessário. A diferença entre executar uma consulta complexa com várias associações com e sem índices apropriados pode ser de dezenas de segundos .

A aplicação é o gargalo. Não é o software. Portanto, apenas melhorar o código principal ou tornar seu modelo menos pesado terá um efeito muito mais dramático no desempenho do que QUALQUER alteração na configuração do MySQL.

O que não nos incomodaria

• Alterando o mecanismo de armazenamento. MariaDB e Percona compartilham o mesmo mecanismo InnoDB - Percona XtraDB. Eles podem ser tratados como um e o mesmo. Em termos de tempo de execução de consulta única - o desempenho espelha exatamente uma compilação do MySQL. Isso entra em jogo sob carga / simultaneidade.
• Executando um escravo do MySQL. Isso não melhorará o desempenho, a menos que o escravo esteja localizado fisicamente mais próximo (da perspectiva da rede) ou que o escravo tenha um hardware melhor que o mestre. Isso entra em jogo sob carga / simultaneidade.
• Executando um servidor de banco de dados externo. Esse é de longe o pior conselho que recebemos repetidamente por muitos hosts / agências. Até você atingir o limite máximo de hardware / recursos ou obter vários servidores web (leia-se: alta disponibilidade), o MySQL na máquina local para uma loja Magento é uma boa idéia. Corta toda a sobrecarga e latência da rede. Mesmo uma rede de 100 Gb / s (sim, cem gigabits por segundo) não se compara com um soquete unix local para volume bruto, taxa de transferência e latência.

^s1 Apenas para servidores de banco de dados separados. Não se aplica a servidores de banco de dados locais.

Capacidade total / simultaneidade

O MySQL é o gargalo
Talvez. Mas apenas uma vez que você tenha acertado seu desempenho e capacidade do PHP a ponto de o MySQL estar diminuindo a velocidade. Se você possui o Varnish e o FPC configurados corretamente (não nos mostre quantas tentativas fracassadas já vimos) - o MySQL se tornará um gargalo.

Portanto, além das modificações acima.

• Mude o mecanismo do MySQL. O XtraDB pode se destacar sob carga e mostra benefícios genuínos em uma distribuição MySQL padrão.
• Mantenha-se atualizado com o MySQL. 5.5 executa melhor que 5.0 sob carga.
• Mude o driver PHP MySQL. O PHP 5.3 e mais recente possui um driver MySQL nativo, mas em algumas circunstâncias, encontramos o PHP 5.2 com o driver separado para superar o MySQLND para Magento. Teste você mesmo
• Alterar mecanismo de pesquisa. Mover a pesquisa para SOLR / Sphinx (ou mesmo alguns serviços externos de terceiros) pode realmente aliviar o fardo da carga não transacional (ou seja, pessoas que não fazem pedidos)
• Alterar mecanismo de navegação em camadas. Novamente, o SOLR é um mecanismo brilhante para navegação em camadas e, devido à sua natureza sem travamento, é muito mais rápido que o MySQL.
• Adicione um escravo do MySQL. Isso faz ajuda de navegação de carga (não transacional), mas não vai ajudá-lo a processar mais pedidos por hora -, pois é dependente do Mestre para processar e replicar esses dados

O que não nos incomodaria

• Mestre / Mestre. Devido ao alto ponto de inflexão da saturação de hardware de uma configuração Master / Slave (superior a 1000 pedidos por hora) - nunca achamos necessário usar o Master / Master na produção. Realizamos testes extensivos, mas nunca consideramos vantajoso do ponto de vista de desempenho e, com os riscos e problemas inerentes ao Master / Master, simplesmente não vale a pena.

Escalabilidade de leitura versus gravação

O último parágrafo realmente leva a uma área importante de escalabilidade de leitura e gravação. A escala de leitura pode ser executada infinitamente, sem muita complicação, com a adição de mais e mais escravos.

Dado que a taxa de leituras para gravações do Magento é de cerca de 0,1% - considerando que as gravações não devem ser uma preocupação. É por isso que não me incomodei em mencionar o MySQL Cluster e seus recursos inteligentes, como compartilhamento automático (dividindo tabelas em máquinas separadas).

Hardware, hardware, hardware

O hardware é facilmente a resposta mais rápida quando se trata de aprimoramento, por isso não o mencionei deliberadamente acima nos dois cenários.

Mas todas as mudanças de software no mundo não farão diferença se o hardware subjacente for insuficiente. Isso pode significar ...

• Switches de baixa qualidade com buffers limitados
• Links de rede excessivamente saturados
• Servidores geograficamente distantes
• Rede ruim QoS / CoS
• Quantidade total limitada de RAM
• RAM de largura de banda com pouca memória
• Subsistema de HDIs com baixas IOPs
• Controlador RAID de software
• CPU com velocidade de clock baixa
• Chipset de baixa largura de banda
• Virtualização de hardware (quase todos os tipos, exceto a virtualização no nível do kernel)

Atualmente, existe um teto realmente alto sobre o quão alto você pode escalar no hardware. Vamos ignorar o mito da escala infinita "na nuvem", pois o hardware da nuvem tende a ser bastante medíocre. Por exemplo, os principais modelos da Amazon são apenas 12 núcleos a 3,3 GHz. Mas fora disso, existem alguns servidores muito poderosos disponíveis - nosso servidor principal possui 160 núcleos e 2 TB (sim, Terabytes) de RAM. Ainda não vimos ninguém exceder as capacidades disso.

Portanto, você tem um amplo escopo para o dimensionamento vertical, antes mesmo de considerar o dimensionamento horizontal.

O alvo sempre em movimento

Vale ressaltar que, na busca pelo desempenho, o gargalo sempre continuará em movimento.

Para uma loja Magento em estoque.

Ative os caches. PHP é o gargalo
Adicione um cache de back-end. PHP é o gargalo
Adicione um cache de página inteira no nível do aplicativo. PHP é o gargalo
Adicione um cache de front-end no nível do servidor (por exemplo, Varnish). MySQL é o gargalo
Adicione um mecanismo alternativo de pesquisa / navegação em camadas (por exemplo, SOLR / Sphinx). PHP é o gargalo
Adicione mais servidores de aplicativos. MySQL é o gargalo
Adicione um escravo do MySQL. Cache de front-end é o gargalo
Adicione mais servidores de cache de front-end. PHP é o gargalo
Adicione mais servidores de aplicativos. SOLR / Sphinx é o gargalo

Etcetera.

Torna-se praticamente um caso de repetição de lavagem e lavagem. Mas o que é claro para entender é que o MySQL certamente não é a primeira porta de otimização - e realmente só entra em jogo quando o MySQL está consumindo mais CPU proporcionalmente ao PHP - e isso SÓ acontece quando o FPC e o Varnish estão em uso e o (s) servidor (es) processam apenas pedidos e nada mais (porque todo o resto está em caches).

Não faça alterações às cegas

Simplesmente adicionar um escravo do MySQL, porque você leu acima, diz que isso ajudará, pode custar desempenho e confiabilidade em um nível enorme. Uma rede congestionada, um servidor escravo com baixa especificação ou até configurações incorretas podem causar problemas de replicação que podem tornar sua loja mais lenta do que era no início - ou causar problemas de sincronização entre o Mestre e o Escravo.

Para colocar as coisas em perspectiva - alguns exemplos do mundo real.

Exemplo 1 - 300 pedidos por hora

Usamos o seguinte hardware para atender 300 pedidos por hora ; e somente nesse ponto de inflexão - sentimos a necessidade de adicionar um servidor MySQL dedicado e um escravo local do MySQL.

1
CPU do servidor : 2x Intel E5-4620
RAM: 64GB HDD: 4x SSDs de 80k IOP / s
RAID: RAID de hardware 10
Versão Magento: Magento EE
OS: MageStack

Durante todo o tempo, as médias de carga permaneceram abaixo de 3,00.

Exemplo 2 - 180 pedidos por hora

Apenas dois dias atrás, um novo cliente nosso absorveu facilmente um grande pico de tráfego. Processando 180 pedidos por hora com um servidor único e Magento Community Edition .

1
CPU do servidor : 2x Intel E5-4620
RAM: 64GB HDD: 4x SSDs de 80k IOP / s
RAID: Hardware RAID 10
Magento Versão: Magento CE
OS: MageStack
Site: Wellgosh.com

Durante todo o tempo, as médias de carga permaneceram abaixo de 6,00. A carga foi maior nesse cenário e isso se reduziu a alguns fatores.

1. Nenhum ajuste do lado da loja foi realizado como no Exemplo 1
2. A falta de um FPC no nível do aplicativo

E, dada a atualidade disso, ainda temos as estatísticas detalhadas para fornecer algum feedback por meio de gráficos. Eles contam uma excelente história de como a carga é distribuída entre os principais componentes de uma arquitetura Magento separada (balanceador de carga, servidor web, servidor db etc. - usando o MageStack ).

Então, da frente para trás ... a data que você deseja ver é às 00:00 do dia 22 de fevereiro.

Pacotes de firewall

Tráfego Verniz

Tráfego Nginx

Carga do MySQL

Carga da CPU

E o mais importante, distribuição de carga

Esta imagem realmente conta tudo. E é que o MySQL certamente não é um fardo - ainda não pelo menos. Portanto, nosso conselho, concentre suas preocupações de desempenho em outro lugar, a menos que você esteja processando mais de alguns milhares de pedidos por hora.

E em resumo

Fazer alterações no desempenho não é "tamanho único". É o caso de analisar seus gargalos atuais e fazer mudanças / ajustes sutis para se adequar à sua loja e infraestrutura.

Mas desempenho à parte, há outros benefícios em usar o Percona

Nós usamos o Percona XtraDB, quase que exclusivamente. Executamos compilações personalizadas do MySQL que desenvolvemos especificamente para o Magento e consultamos a Percona durante o processo. Mas não foi apenas o desempenho que influenciou essa escolha.

• O kit de ferramentas Percona
  • pt-query-digest
  • xtrabackup
  • etc.
• Freqüência de liberação Percona
• Suporte consultivo da Percona
• O cache morno é reiniciado com a preservação do pool do InnoDB

E muito mais. Portanto, usá-lo no MySQL tinha outras vantagens além do desempenho. De fato - o MySQL é e sempre foi a menor das nossas preocupações na busca de desempenho e estabilidade.

Atribuições: wellgosh.com , sonassi.com , iebmedia.com .