PrestaShop System Performance

Machine Translated by Google
Desempenho do Sistema Prestashop

Papel branco
Versão 1.0 - 26/01/2021
Prestashop System Performance White Paper Versão 1.0 1

Prólogo
O desempenho é uma disciplina excitante, variada e desafiadora.

— Brendan Gregg
Você está usando a PrestaShop para desenvolver seu negócio e temos o prazer de acompanhá-lo nesse
caminho. Com o crescimento dos negócios, os comerciantes querem saber mais sobre a capacidade de
desempenho e escala de sua solução.
A PrestaShop foi desenvolvida com base em tecnologias maduras e robustas usadas por alguns dos sites
mais visitados do mundo. As soluções implementadas para alcançar o melhor desempenho e escala no
topo desta pilha técnica são bastante padronizadas e bem conhecidas. Este white paper listará quais você
pode usar no contexto da PrestaShop e o que pode esperar deles.
“Se você não pode medir, não pode melhorar” é uma citação famosa do guru da administração Peter
Drucker, mas também se aplica ao campo de desempenho de software. É por isso que grande parte deste
White Paper se concentrará na própria metodologia de benchmark, a fim de fornecer as ferramentas para
avaliar o desempenho de sua configuração e garantir que as melhorias sejam eficazes em seu
caso.
Este white paper fornece orientação sobre como melhorar sua instalação PrestaShop otimizando sua
configuração e infraestrutura.
«Qual melhoria de infraestrutura para

atender mais visitantes e vender mais ?»

Índice
Prólogo 2
Índice 3
Contexto de referência 5
A loja que estamos testando 5
Loja de hospedagem 5
Versão da loja 5
perfil da loja 5
Rede 6
Cenários de referência 7
Cenários distintos 7
Rastreamento do FrontOffice - Contagem de visitantes 7
Pedido FrontOffice - Contagem de Clientes 7
Evitando a aleatoriedade 7
Tempos de resposta aceitáveis 8
Tempo de resposta 8
Visualizações de página por hora 8
resultados de referência 9
Arquitetura de servidor único 9
Servidor único com apache2 webserver Servidor 9
único com php-fpm Servidor único 11
com php-fpm e tuning Servidor único com php-fpm e 14
tuning e discos SSD Servidor único com php-fpm e tuning e discos SSD 16
ampliados ! 18
Servidor único com nginx php-fpm e discos de ajuste e SSD dimensionados! 20 Servidor único ajustado
e dimensionado com os clientes Arquitetura de banco de dados 22
externalizada 25
Servidor de banco de dados externalizado com php-fpm e tuning e discos SSD Servidor 26
de banco de dados externalizado com php-fpm e tuning e discos SSD ampliados ! 28
Servidor de banco de dados externalizado com php-fpm e discos de ajuste e SSD dimensionados
com clientes! 30
Percepções 32
Recomendações 36
Próximo 37
Anexos 38

Fontes externas 38
PrestaShop 38
PrestaShop Devdocs 38
PrestaShop Docker 38
Modelos de Docker PrestaShop 38
Projeto de Performance Prestashop 38
Loja de Hospedagem 39
Armazenamento em nuvem 39
Nuvem SQL 39
Docker 39
Ajuste de configurações 40
PHP Tuning 40
MySQL Tuning 41

Contexto de referência
O benchmarking testa o desempenho de maneira controlada, permitindo que as escolhas sejam

comparadas e os limites de desempenho sejam compreendidos — antes de serem
encontrados na produção.
-Brendan Gregg
O PrestaShop é o conhecido software de código aberto que você pode baixar e executar com quase todas
as empresas de hospedagem. Você é livre para configurar sua loja, instalar extensões e modificar o código
da maneira que desejar para atender às suas necessidades específicas.
Como cada configuração do PrestaShop é única, sua milhagem pode variar em relação aos benchmarks
que você encontrará neste documento.
Isso também significa que não pode existir nenhum benchmark perfeito, abrangendo todas as configurações
possíveis.
Mas tivemos que escolher um, julgando-o relevante o suficiente e forneceremos todas as informações
necessárias para reproduzir os cenários e permitir que você verifique onde está com nossa própria
configuração.
a. A loja que estamos testando I.

Hospedagem da loja
Em nosso contexto, decidimos usar um ambiente facilmente reproduzível usando o docker e o Google
Compute Engine. Tendo executado quase 2.000 testes, a facilidade de configuração por automação foi
essencial. Essa foi uma suposição honesta de que o docker não se desviaria muito de uma configuração
bare metal. Você encontrará mais detalhes sobre a solução de hospedagem nos Anexos.
II. Versão da loja

Estamos usando a versão mais recente do PrestaShop disponível no momento em que este livro foi
escrito: versão 1.7.6.3, rodando com php 7.2. Usando o docker, usamos os oficiais fornecidos pela
empresa PrestaShop.
III. perfil da loja

O Prestashop é usado em todos os tamanhos de lojas em todo o mundo, desde lojas de um único
produto até dezenas de milhares de catálogos de produtos.

Escolhemos um conteúdo de tamanho médio, com 1000 produtos, 10 fornecedores, 2 idiomas,

5 categorias, 1000 comandos que resultam em um tamanho de banco de dados em torno de 140Mb.
4. Rede
Dependendo do terminal e da rede do visitante, os tempos de carregamento das páginas podem variar muito.
Sabendo disso, nosso objetivo aqui é focar no Tempo de Resposta: um tempo aceitável para gerar e
baixar a página.
Para fazer isso de maneira aceitável, estamos executando nosso teste em outra instância do GCP,
executando gatling em um contêiner docker e acessando a loja por meio de uma rede pública, assim:

b. Cenários de referência
I. Cenários distintos
Definimos vários cenários, cada um deles refletindo um uso particular das funcionalidades de um
site de comércio eletrônico:
• Rastreamento do FrontOffice - Contagem de visitantes
Este é o cenário mais utilizado, com visitantes navegando, abrindo categorias e páginas de
produtos. Nosso objetivo é simular um visitante padrão navegando em uma velocidade média
nas diferentes páginas.
Escolhemos o valor arbitrário de abrir 15 páginas por sessão, com uma pausa após cada
abertura de página variando entre 0 e 5 segundos.
• Pedido FrontOffice - Contagem de Clientes
Uma pequena parte dos visitantes se converterá em clientes adicionando produtos ao carrinho e
fazendo um pedido. Optamos por adicionar apenas um produto no carrinho. São necessários 8
carregamentos de páginas por colocação de pedido (exibir produto, adicionar ao carrinho,
digitar nome, endereço, escolher transportadora...).
II. Evitando a aleatoriedade

Abrir páginas aleatórias levaria a resultados não repetíveis. É por isso que usamos apenas cenários
predefinidos. A abertura aleatória de páginas poderia ser utilizada em testes de estresse, o que não
é o escopo deste estudo.

C. Tempos de resposta aceitáveis
Decidimos que esse tempo de resposta aceitável deve ser definido como 300 ms para a navegação dos
visitantes (página do produto/categoria) e 1,0 s para o processo de checkout (adicionar um produto ao carrinho,
fazer o pedido).
Manter essa medição abaixo do limite definido nos fornece o KPI de usuário por hora com
valor comercial, que é a contagem máxima de cenário com suporte para ficar abaixo do limite de tempo de
resposta.
Obviamente, se você decidir aceitar tempos de resposta mais altos, isso também aumentará o número
máximo de visitantes simultâneos que obtemos como resultado. Escolhemos um tempo de resposta baixo
para garantir que não produzamos falsas expectativas. (O tempo médio de reação humana é da ordem
de um quarto de segundo 250 milissegundos)
I. Tempo de resposta
É o tempo de resposta quando o sistema está sob carga.

Para obter resultados reprodutíveis, usamos os valores do “95º percentil” . Isso exclui
valores não representativos, que podem ser causados por latência de rede anormal, processo de
condição de corrida ou algum outro não reproduzível
estados.
II. Visualizações de página por hora

Usuários por hora é o número de usuários que podem rastrear a loja durante uma hora enquanto
permanecem abaixo do limite de tempo de resposta aceitável.
Como já mencionado, existem 2 tipos de usuários: • Visitantes,
rastreando a loja em busca de produtos • Clientes,
adicionando um produto ao carrinho, preenchendo o endereço,
etc..
Para descobrir esse KPI para cada configuração de loja, realizamos testes gatling, com os usuários
(Visitantes ou Clientes) distribuídos uniformemente durante o teste
correr.

2.Resultados de referência
Existem mentiras, malditas mentiras e existem medidas de desempenho.

— Anon et al., “A Measure of Transaction Processing Power” [Anon 85]
a. Arquitetura de servidor único

Nesta seção, vamos comparar a configuração mais comum disponível para
hospedar uma solução PrestaShop: um único servidor, hospedando o servidor
web, o php runtime e o banco de dados MySQL.
Algumas outras configurações existem, é claro, elas podem ser menos comuns e
podem adicionar alguma complexidade que nem todas as configurações exigem
(especialmente ao lidar com vários frontends).
eu. Servidor único com servidor web apache2

A arquitetura mais comum disponível ao configurar uma loja: um servidor executando todos
os serviços necessários e o apache2 renderizando as páginas php.

Configuração Resultado
Servidor Configurar Máximo de visitantes por hora
- Apache2 +
1 vCPU/ módulo php
3,75 Gb RAM - MySQL 220
disco: padrão - Configuração fora da
caixa
Bem, esse é o nosso primeiro resultado. Não é ruim, mas não se preocupe: esse é apenas o primeiro teste de
uma longa série!

ii. Único servidor com php-fpm

A próxima melhor coisa ao discutir o desempenho do php é php-fpm. Infelizmente, raramente vemos qualquer
comparação prática entre os verdadeiros potenciais das duas soluções. Achamos que era a
oportunidade perfeita e executamos o mesmo teste (com exatamente a mesma contagem de visitantes) contra
a pilha php-fpm.
Claro, tivemos que atualizar um pouco a configuração, principalmente introduzindo um tempo de execução
php-fpm, mas tudo ainda roda na mesma pilha de docker, em uma única instância do GCP Compute,
dimensionada da mesma maneira:
E aqui estão os resultados, cerca de 60% do número de visitantes em relação à configuração anterior!
- Módulo Apache2 + php

1 vCPU/
3,75 Gb RAM - MySQL 220
disco: padrão - Configuração fora da
caixa
1 vCPU/ - Apache2 + php-fpm

- MySQL
3,75 Gb RAM
- Configuração fora da 360
disco: padrão
caixa

O que já é um número interessante de se alcançar por si só, apenas passando do

apache2 com módulo php para php-fpm.
Outro fato interessante é que a taxa de CPU é muito mais eficiente com PHP-FPM
do que com o módulo apache2:
Consumo de CPU e ambiente de produção Observe

que, para seus ambientes de produção, você prefere permanecer abaixo dos 40% de uso
da CPU, permitindo que qualquer surto de atividade seja gerenciado normalmente.
Como você verá em nossos testes restantes, não há razão para o aplicativo parar de
funcionar com eficiência ao exceder os 40% de uso da CPU, isso é apenas uma
precaução para garantir a estabilidade e a experiência do usuário caso você
tenha um pico de usuários.

Além disso, olhando para a E/S do disco:
Uso de E/S de disco

Para verificar o uso do disco, fizemos alguns cálculos: • Primeiro, pegamos
o número de operações que o disco poderia gerenciar e
multiplicado pelo tamanho do bloco. Para disco padrão: 75 (número de operações de
gravação) x 4 (tamanho do bloco) = 300 •
Em seguida, pegamos o número de gravações de disco que tínhamos, 64, e dividimos pelo número
de operações permitidas: 64 / 300 = 0,21 , portanto, 21% da gravação em disco
uso
• Obviamente, um disco SSD pode executar muito mais operações, 1500 para ser exato:
1500 (número de operações de gravação) x 4 (tamanho do bloco) = 6000

iii. Servidor único com php-fpm e tuning

Mesmo assim, tínhamos certeza de que mais poderia ser feito. Que ainda poderíamos obter mais
visualizações de página. Portanto, revisamos nossas configurações completamente e as ajustamos,
principalmente aplicando todas as opções de cache disponíveis (seja do tempo de execução do php ou do
mysql).
Você encontrará esses parâmetros no final deste documento na seção Anexos, mas sem mais delongas, aqui
estão os resultados:
1 vCPU/ - Apache2 + php-fpm

- MySQL
3,75 Gb RAM
- Configuração fora da
360
disco: padrão
caixa
1 vCPU/ - Apache2 + php-fpm ajustado
3,75 Gb RAM 740
disco: padrão - MySQL ajustado
Além disso, estamos vendo um grande aumento no uso do Disk IO, o que explica a contenção que começa a
desacelerar o aplicativo, mesmo depois de habilitar o cache. Veremos se isso coincide com nosso próximo
teste!

Validade do uso da CPU

Obviamente, o uso da CPU está longe de ser o único indicador do desempenho e
integridade de um aplicativo. Bem, dependendo de como você o lê.
No nosso caso, um alto uso da CPU significa que a maioria dos outros gargalos (discos,
IOs, processos paralelos, etc.)

4. Servidor único com php-fpm e tuning e SSD

discos
Como a documentação do Google Compute coloca: “Os discos permanentes SSD são adequados para
aplicações corporativas e necessidades de banco de dados de alto desempenho que exigem menor
latência e mais IOPs do que os discos permanentes padrão fornecem”. Com nosso banco de dados e aplicativo
armazenados no mesmo servidor e disco, faz todo o sentido usá-los.
E aqui estão os resultados:
1 vCPU/ - Apache2 + php-fpm ajustado

3,75 Gb RAM 740
disco: padrão - MySQL ajustado
Disco - Apache2 + php-fpm ajustado

RAM de 1 vCPU/ 900
3,75 Gb : SSD - MySQL ajustado
Poderíamos esperar um ganho maior ao mudar para SSD, mas lembre-se de que a maioria das otimizações
de configuração realizadas na última etapa foram sobre armazenamento em cache e buffer. Além disso,
vimos que estávamos chegando ao limite de capacidade do disco, não atingindo. Com isso em mente, ainda é
uma boa lacuna de desempenho: como podemos ver, ele fornece ainda mais espaço para a CPU gastando
ainda menos tempo de recursos para outras tarefas (como discos e operações de E/S) para gerenciar a carga
do aplicativo:

Além disso, é interessante ver que com o disco SSD, vemos uma grande diminuição no uso de
operações de gravação em disco:
Informe que não é porque estamos realizando menos gravações, mas porque os discos SSD podem
gerenciar muito mais operações de gravação do que os discos padrão.

v. Servidor único com php-fpm e tuning e discos SSD

ampliados!
E agora aumentamos os recursos do servidor em 4 para RAM e CPU!
Será que nosso amado aplicativo PrestaShop consegue gerenciar tanto cavalo de força?
Achamos que sim, mas veja por si mesmo:
Disco
- php-fpm ajustado
RAM de 1 vCPU/
- MySQL ajustado
900
3,75 Gb: SSD
4 vCPU/
- php-fpm ajustado
Disco RAM
- MySQL ajustado
2810
de 15 Gb: SSD

Aumente as expectativas
Muitas vezes, há um entendimento de que dobrar os recursos da instância (CPU e RAM) deve dobrar os
resultados do aplicativo. Na vida real, isso não é tão fácil, por vários motivos:
• Orquestração, execução de filas e troca de contexto, quase invisíveis, levam algum tempo
recursos e tempo do kernel
• Gargalos podem não ser CPU ou RAM. Pode aparecer como CPU no seu
monitoramento, mas isso pode indicar que o tempo da CPU é gasto esperando por outros recursos
(rede, discos e assim por diante)
Ampliação da
nuvem Um fato pouco conhecido sobre a expansão de instâncias com soluções de computação em nuvem é que
você não apenas adiciona CPU e/ou RAM, mas também recursos potencialmente menos óbvios: E/S,
largura de banda de rede e assim por diante.
O que é sempre bom ter mais.

vi. Servidor único com nginx php-fpm e tuning

e discos SSD ampliados!
Frequentemente ouvimos debates sobre o desempenho do nginx melhor que o apache2 e o vice
versa.
Embora tenhamos nossa ideia sobre isso, pensamos que seria interessante compará-los e verificar por nós
mesmos.
Aqui está a pilha que usamos, exatamente a mesma do teste anterior, apenas substituindo apache2 por nginx:
4 vCPU/ - apache2+php-fpm ajustado

Disco RAM de 2810
15 Gb: SSD - MySQL ajustado
4 vCPU/
- nginx+php-fpm ajustado
15 GB RAM
- MySQL ajustado
2390
disco: SSD
O que é muito bom por si só, mas não exatamente o que o apache2 oferece.

Nossa opinião sobre o Apache e o Nginx

Ambos são ferramentas de primeira linha, embora seu funcionamento interno seja muito diferente.
Para encurtar a história, o nginx é melhor em lidar com conteúdo estático e o apache2 é melhor
em lidar com conteúdo dinâmico.
O design assíncrono do nginx adiciona alguma latência ao renderizar páginas dinâmicas (tempo de loop
de evento), aumentando ligeiramente os tempos de resposta.
Por outro lado, esse design assíncrono permite gerenciar cargas mais altas e lidar melhor com conteúdos
estáticos (como imagens, css ou arquivos javascript).
Portanto, não existe realmente uma solução melhor que a outra, isso realmente depende de suas
expectativas e casos de uso.
Mas nada impede que você use os dois, além de uma pequena complexidade técnica acumulada.

vii. Servidor único ajustado e dimensionado com os clientes

E agora, nosso teste final para esta arquitetura: misturar Visitantes e Clientes e observar o que
acontece nesta situação.
Máximo de visitantes Máximo de clientes

Servidor Configurar
Por hora Por hora
4 vCPU/ - apache2+php-fp m
15 GB RAM sintonizado 2700 110
disco: SSD - MySQL ajustado
Como você pode ver, diminuímos um pouco a contagem de visitantes, vamos explicar o motivo: •
Durante o teste anterior, estávamos perto do tempo máximo de resposta
permitido para este benchmark - não significa que atingimos o limite do sistema, longe disso,
apenas os parâmetros do teste
• Portanto, se apenas adicionássemos alguns clientes, teríamos ultrapassado os 300ms
limite com certeza
• A proporção aceita entre Visitantes e Clientes sendo de 4%, adicionamos 110 Clientes (2740 x
0,04 = 109,6)
• Portanto, removemos 110 visitantes e adicionamos 110 clientes • Como
você pode ver, para este teste e ambiente, temos uma proporção interessante de quase 1 cliente
por visitante - veremos mais tarde se isso ocorre em outros cenários

É interessante ver um leve aumento nas operações de gravação em disco. Isso é facilmente explicado,
pois as operações do cliente envolvem mais gravações de banco de dados do que as operações
dos visitantes:


Alcançando os limites
Como você pode ver neste gráfico, estamos atingindo os limites desta arquitetura:
Obviamente, o aplicativo ainda pode funcionar conforme o esperado e não deve quebrar se o
limite for atingido, mas:
• Qualquer carga adicional (externa de visitantes ou interna de funcionários)
aumentará consideravelmente o tempo de resposta
• Qualquer explosão de atividade pode ser mal gerenciada pelo servidor, resultando em
desempenho percebido por qualquer visitante ou cliente
Para seus ambientes de produção, você prefere permanecer abaixo dos 40% de uso da
CPU, permitindo que qualquer pico de atividade seja gerenciado normalmente.

b. Arquitetura de banco de dados externalizada
Nesta arquitetura, externalizamos o banco de dados MySQL para o serviço Cloud SQL, com
recursos dedicados.
O que se poderia esperar é que:
- Mais recursos devem estar disponíveis tanto para o aplicativo quanto para o banco de dados
- O gerenciamento de aplicativos e infraestrutura é mais fácil (backups, migrações,
etc.)

eu. Servidor de banco de dados externalizado com php-fpm e tuning e

discos SSD
Como já experimentamos as diferentes configurações de tuning disponíveis, partimos diretamente delas
incluídas nesta arquitetura.
E aqui estão os resultados:
Servidores Configurar Máximo de visitantes por hora
Web
1 vCPU/
3,75 Gb RAM
- apache2+php-fpm ajustado
disco: SSD
DB - MySQL ajustado 940

1 vCPU/ - MySQL externalizado
3,75 Gb RAM
disco: SSD
Web & DB 1
- Apache2 + php-fpm ajustado
vCPU/
3,75 Gb RAM - MySQL ajustado
900
disco: SSD - Mysql com Apache

Como você pode ver, o uso da CPU do banco de dados é bastante baixo.
Porém, lembre-se que as operações de back office, não contempladas nos testes atuais, podem
ser muito intensas para o servidor BD, principalmente com alguns módulos ativados, o que
é outro bom motivo para externalizar o servidor BD.

iii. Servidor de banco de dados externalizado com php-fpm e tuning

e discos SSD ampliados!
Aqui, apenas aumentamos a instância do aplicativo, quadruplicando sua RAM e CPU.
Como vimos os recursos do banco de dados estão longe de atingir seus limites, não estamos
atualizando, mantendo sua configuração atual:
Servidores Configurar Contagem máxima de visitantes
Web
1 vCPU/
3,75 Gb RAM
disco: SSD - php-fpm ajustado
DB
- Exteriorizado afinado 900
MySQL
1 vCPU/
3,75 Gb RAM
disco: SSD
Web
4 vCPU/
Disco RAM
de 15 Gb: SSD - php-fpm ajustado
DB
- Exteriorizado afinado 2550
MySQL
1 vCPU/
3,75 Gb RAM
disco: SSD


4. Servidor de banco de dados externalizado com php-fpm e discos

de ajuste e SSD dimensionados com clientes!
E agora adicionamos alguns clientes aos grupos de usuários e vemos como a pilha reage:
Máximo de visitantes por Máximo de clientes

Servidor Configurar
Hora Por hora
Web
4 vCPU/
Disco RAM de
- php-fpm ajustado
15 Gb: SSD - Exteriorizado
DB afinado 2410 100
1 vCPU/ MySQL
3,75 Gb RAM
disco: SSD

Novamente, um ligeiro aumento da operação de gravação de disco no lado do banco de dados, explicado pelo
Cenário de clientes envolvendo mais gravações:

1. Informações
Agora que testamos o aplicativo PrestaShop com várias configurações e arquiteturas, aqui estão alguns
insights que gostaríamos de compartilhar com você:
• Mesmo para uma arquitetura de instância única, a configuração pode fazer uma grande diferença. Pode
parecer óbvio para a maioria, mas ainda é algo que precisa ser dito e dito novamente. Aqui, quase
200% de visitantes por hora podem ser obtidos com um pouco de amor e configuração.
• Aparentemente, não vimos muitas melhorias ao externalizar o banco de dados durante os testes, o
que pode ser uma avaliação justa. No entanto, esse comportamento pode ser esperado por
qualquer dimensionamento horizontal, adicionando sobrecarga de rede à arquitetura da
plataforma.
Além disso, observando a carga dos servidores e o uso de seus recursos, podemos supor
que:
• A arquitetura de instância única atingiu seu limite mais cedo, principalmente
CPU
• Em um cenário do mundo real, a arquitetura externa seria melhor
lidar com qualquer pico de tráfego - pode ser apreciado pelo uso de disco que é menor ao
observar as métricas de banco de dados externalizadas • É sempre
uma boa prática isolar elementos: dessa forma, uma carga de aplicativo não
afetará o banco de dados e vice-versa

• O que inclui, como já mencionado, algumas operações de backoffice que podem ser bastante
pesadas no banco de dados
• Como vimos durante esta série de testes, a carga da rede NÃO deve ser
subestimado ao trabalhar em sua arquitetura, e mesmo uma boa capacidade de rede não
impedirá a perda de desempenho:

• Outro insight é que, embora muito diferentes em seus designs, em nosso caso, o
apache2 é mais adequado do que o nginx:


2.Recomendações
Fornecemos a você muitos dados e cabe a você decidir quais são relevantes para o seu caso.
Ainda assim, temos algumas palavras para compartilhar com você sobre o que consideramos ser
as melhores práticas.
Em primeiro lugar, uma boa configuração do servidor trará muitos desempenhos.

Continuaremos compartilhando-os com você através do nosso site devdocs.
Além disso, sim, a mono-instância é muito eficiente.

E sim, a instância mono é muito fácil de configurar.
Mas há muitas áreas em que a arquitetura de instância única não atenderá às suas necessidades
e esses testes de desempenho não as mostrarão a você.
Em primeiro lugar, a mono-instância NÃO gerenciará alta disponibilidade: tendo apenas uma instância
do seu amado PrestaShop, qualquer falha de hardware, reinicialização do servidor ou qualquer
alteração de configuração pode gerar indisponibilidade, o que pode ser perigoso para o seu
negócio.
Além disso, falando em desempenho, você precisa de instâncias dedicadas para ajustar seu
aplicativo: o apache não requer a mesma configuração do MySQL (overcommit, agendadores
de filas, etc.). Esse tipo de ajuste fino só pode ser alcançado separando a parte de seu aplicativo
para servidores dedicados.
Portanto, embora um pouco menos eficiente (o que, novamente, é de se esperar ao adicionar

servidores e sobrecarga de rede), recomendamos separar as partes dos aplicativos
em diferentes servidores.
Isso também lhe proporcionará um melhor gerenciamento da plataforma, seja gerenciando

backups de forma eficiente, adicionando escravos MySQL para segurança e distribuindo
os recursos necessários - talvez seu banco de dados não precise de tanta CPU quanto seu
frontend, ou talvez exija mais, dependendo suas necessidades, mas isso é algo que você pode
gerenciar apenas ao dividir sua arquitetura.
E isso irá prepará-lo para configurações de alta disponibilidade que se tornarão vitais
quando sua loja crescer e você precisar de melhor tempo de atividade e melhor tempo de
resposta. Conceitos com os quais esperamos que você se familiarize e que apresentaremos a
você em documentos futuros, se ainda não for o caso.

Por fim, permitirá que você gerencie melhor seus visitantes e clientes no final, sejam surtos ou
apenas algumas solicitações SQL de backoffice que definitivamente afetarão menos sua atividade
de front-end.
3.Próximo
As melhorias de configuração e infraestrutura apresentadas neste white paper são bastante simples de
implementar e podem fornecer ganhos de desempenho interessantes.
Em um próximo white paper, exploraremos configurações mais avançadas que podem ser apropriadas
se você já estiver atingindo os limites delas.
Cache: uso de um proxy reverso, como verniz, para melhorar muito o desempenho de
leitura.
Dimensionamento horizontal: configuração de mais de um servidor de aplicativos por trás de um
balanceador de carga para melhorar o desempenho e a disponibilidade.

Anexos
Fontes externas
PrestaShop
Claro, não poderíamos ter uma seção de recursos sem mencionar o repositório github
do PrestaShop! É aqui que a maior parte da magia está a acontecer e onde se podem encontrar
a maioria das pessoas envolvidas no projeto, seja para pedir a sua ajuda ou para lhes fornecer
alguma : https://github.com/PrestaShop/PrestaShop
PrestaShop Devdocs
Você encontrará muitos recursos úteis aqui, desde o desenvolvimento da solução até a
hospedagem e até mesmo o teste.
Não hesite em fazer uma visita, há boas chances de você encontrar algo que
procurava: http://devdocs.prestashop.com/
PrestaShop Docker
Aqui é onde as fontes de imagens do docker PrestaShop são trabalhadas, para então
serem disponibilizadas pelo docker hub. Os mesmos que usamos para este
artigo. https://github.com/PrestaShop/docker
https://hub.docker.com/r/prestashop/prestashop
Modelos de Docker PrestaShop

Um pequeno repositório onde fornecemos alguns modelos e soluções de arquitetura para
sua PrestaShop hospedada em docker. Os mesmos que usamos aqui.
https://github.com/PrestaShop/docker-templates
Projeto de Performance Prestashop

Por último, mas não menos importante, um conjunto de testes para comparar sua instância
PrestaShop da criação de imagem do docker com produtos para executar os testes gatling. O
mesmo que
usamos aqui. https://github.com/PrestaShop/performance-project

Loja de Hospedagem
Aqui estão alguns detalhes sobre as soluções de hospedagem que usamos durante esses testes.
Armazenamento em nuvem
As infraestruturas de nuvem fornecem ferramentas prontas para uso para implantação e monitoramento de
aplicativos. A sobrecarga da virtualização é um custo aceito para obter uma infraestrutura fácil de
alterar e executar esses cenários com rapidez suficiente.
Nuvem SQL
Como diz o Google, “Cloud SQL é um serviço de banco de dados totalmente gerenciado que facilita a
configuração, manutenção, gerenciamento e administração de seus bancos de dados relacionais no Google
Cloud Platform”.
Estamos usando-o para a arquitetura de banco de dados externalizada.
Docker
Da mesma forma, a utilização do docker permite configurações reutilizáveis, não só definindo o código
(instalação da loja, luminárias, etc...) como também os softwares (versão e configuração do php, apache e php-
fpm, etc...).

Ajuste de configurações
Para que você reproduza nossos testes ou se inspire em nossas configurações, estamos
fornecendo-os como os usamos.
Informe que esses parâmetros de configuração podem não ser adequados para o seu ambiente e
podem exigir algum trabalho extra para um ambiente de produção real.
Por exemplo: definir opcache valid_timestamps como 0 pode não ser adequado para você, pois qualquer
alteração no código do aplicativo exigiria que seu servidor da Web fosse reiniciado para ser levado em
consideração.
Além disso, estamos plenamente conscientes de que poderíamos ter adaptado as configurações para cada
configuração e ir ainda mais longe na parte de ajuste (como ajustar o gerenciador de processos do php-fpm,
ajustar o agendador do sistema operacional, o agendador de IO, etc.), mas : • Não é nossa intenção ir tão
longe neste documento • Teria aumentado o número de casos de teste
• Fazendo isso, teria sido mais difícil comparar cada solução entre eles
• Essas opções de configuração raramente estão disponíveis na maioria das soluções de hospedagem
Ajuste do PHP
Como vimos, o ajuste do PHP é muito importante para o desempenho do seu aplicativo, esteja
você executando o PrestaShop ou qualquer outro software PHP.
Especialmente se você estiver lidando com o desempenho do sistema de arquivos e NFS.
Aqui estão as opções que ajustamos:
Realpath
Cada vez que um arquivo é incluído no código executado, o PHP precisa procurá-lo e analisá-lo, o que
pode rapidamente se tornar pesado para o sistema de arquivos (e nem contar como IO, é apenas uma
pesquisa), executando comandos lstat continuamente .
Portanto, ativar o cache do realpath é sempre uma boa ideia, especialmente com um sistema de arquivos
compartilhado (como o NFS).
> realpath_cache_size = 4096k >

realpath_cache_ttl = 600
Memória
Embora o PrestaShop não exija tanto consumo de memória, algumas páginas de backoffice podem exigir mais
memória. Como é recomendado por padrão, estamos fazendo isso com prazer.
> limite_de_memória = 512M

OPCache
Como você deve saber, PHP não é uma linguagem compilada, ou seja, toda vez que você
a executa, o sistema a compila em bytecode para execução. E aí vem o OPCache!
Ele compila e armazena o código na memória ativa para melhorar o tempo de execução.
E funciona muito bem, como você deve ter visto.

Lembre-se de que algumas configurações podem exigir que você altere a maneira como
costuma fazer as coisas em seu próprio ambiente. Por exemplo,
opcache.validate_timestamps=0 significa que o OPCache nunca atualizará seu código , a
menos que você informe explicitamente (por meio de funções internas ou reiniciando o servidor
da web).
> opcache.enable=1 >

opcache.enable_cli=0 >
opcache.memory_consumption=256 >
opcache.interned_strings_buffer=32 >
opcache.max_accelerated_files=16229 >
opcache.max_wasted_percentage=10 >
opcache.validate_timestamps=0 >
opcache.revalidate_path=0 >
opcache .fast_shutdown=1 >
opcache.enable_file_override=0 >
opcache.max_file_size=0
MySQL Tuning
Embora estejamos discutindo isso em segundo lugar, o ajuste do MySQL é igualmente importante.
Nossa intenção aqui era otimizar o throughput da instância adicionando caches.
Já o PHP permite que o serviço funcione o máximo possível em memória e evite acessos ao disco,
reduzindo assim a latência.
Cache
Como mencionado, esses parâmetros permitem melhores informações de cache para posterior
reutilização, primeiro habilitando-o e depois aumentando seus tamanhos. Novamente, a ideia é
manter os resultados da consulta na memória, em vez de procurá-los no disco rígido (latência mais alta).
Como sempre, esses valores devem ser adaptados ao seu próprio ambiente,
provavelmente você não precisará de um host_cache_size de 10000.
> query_cache_limit = 128K >

query_cache_size = 32M >
query_cache_type = ON >
table_open_cache = 1000 >
thread_cache_size = 80 >
host_cache_size=10000

Buffer
Buffering é quase outra palavra para cache. Portanto, trabalhamos aqui com a área de
memória que contém dados em cache para tabelas InnoDB, índices e outros buffers
auxiliares, etc.
Novamente, essas opções devem ser adaptadas à sua loja. Configuramos o
innodb_buffer_pool_size para 3G apenas para garantir que toda a pilha seja
armazenada em cache na memória, mas certifique-se de ter memória suficiente de acordo
com o valor que você configurou.
> read_buffer_size = 2M >

read_rnd_buffer_size = 1M >
join_buffer_size = 2M >
sort_buffer_size = 2M >
innodb_buffer_pool_size = 3G
Outros parâmetros
Alguns outros parâmetros para aumentar o desempenho do MySQL, como desabilitar o
esquema de desempenho (usado para monitoramento), tabelas de memória e aprimorar
consultas GROUP BY.
> performance_schema = OFF >

max_heap_table_size = 32M >
tmp_table_size = 32M


PrestaShop System Performance

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PrestaShop System Performance

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Machine Translated by Google

Desempenho do Sistema Prestashop

Prestashop System Performance White Paper Versão 1.0 1

O desempenho é uma disciplina excitante, variada e desafiadora.

«Qual melhoria de infraestrutura para

Prestashop System Performance White Paper Versão 1.0 2

A loja que estamos testando 5

Tempos de resposta aceitáveis 8

Visualizações de página por hora 8

Arquitetura de servidor único 9

Servidor único com apache2 webserver Servidor 9

único com php-fpm Servidor único 11

com php-fpm e tuning Servidor único com php-fpm e 14

de banco de dados externalizado com php-fpm e tuning e discos SSD ampliados ! 28

Prestashop System Performance White Paper Versão 1.0 3

Prestashop System Performance White Paper Versão 1.0 4

O benchmarking testa o desempenho de maneira controlada, permitindo que as escolhas sejam

a. A loja que estamos testando I.

II. Versão da loja

III. perfil da loja

Prestashop System Performance White Paper Versão 1.0 5

Escolhemos um conteúdo de tamanho médio, com 1000 produtos, 10 fornecedores, 2 idiomas,

Prestashop System Performance White Paper Versão 1.0 6

• Rastreamento do FrontOffice - Contagem de visitantes

• Pedido FrontOffice - Contagem de Clientes

II. Evitando a aleatoriedade

Prestashop System Performance White Paper Versão 1.0 7

C. Tempos de resposta aceitáveis

É o tempo de resposta quando o sistema está sob carga.

II. Visualizações de página por hora

Prestashop System Performance White Paper Versão 1.0 8

Existem mentiras, malditas mentiras e existem medidas de desempenho.

a. Arquitetura de servidor único

eu. Servidor único com servidor web apache2

Prestashop System Performance White Paper Versão 1.0 9

Servidor Configurar Máximo de visitantes por hora

Prestashop System Performance White Paper Versão 1.0 10

ii. Único servidor com php-fpm

Servidor Configurar Máximo de visitantes por hora

- Módulo Apache2 + php

1 vCPU/ - Apache2 + php-fpm

Prestashop System Performance White Paper Versão 1.0 11

O que já é um número interessante de se alcançar por si só, apenas passando do

Consumo de CPU e ambiente de produção Observe

Prestashop System Performance White Paper Versão 1.0 12

Além disso, olhando para a E/S do disco:

Uso de E/S de disco

Prestashop System Performance White Paper Versão 1.0 13

iii. Servidor único com php-fpm e tuning

Servidor Configurar Máximo de visitantes por hora

1 vCPU/ - Apache2 + php-fpm

Prestashop System Performance White Paper Versão 1.0 14

Validade do uso da CPU

Prestashop System Performance White Paper Versão 1.0 15

4. Servidor único com php-fpm e tuning e SSD

E aqui estão os resultados:

Servidor Configurar Máximo de visitantes por hora

1 vCPU/ - Apache2 + php-fpm ajustado

Disco - Apache2 + php-fpm ajustado

Prestashop System Performance White Paper Versão 1.0 16

Prestashop System Performance White Paper Versão 1.0 17

v. Servidor único com php-fpm e tuning e discos SSD