it-swarm-pt.tech

Dimensionando um WP site de comércio eletrônico

Relacionado a esta questão .

Qualquer recomendação sobre ferramentas, plugins para otimizar um grande site de comércio eletrônico no WP. Atualmente atingindo 1000 itens e mais 5000 itens chegando. Parece que as otimizações seriam diferentes de um blog padrão que atende milhares de usuários. O número de lojas que estão sendo desenvolvidas em WP está aumentando e colocar um pacote de otimizações juntas parece ser útil.

MM/RC

5
RealityCramp

Eu desenvolvi um site de ecommerce de 55k produtos usando o Wordpress com o plugin Shopp e posso compartilhar o que eu fiz com o MySQL para obter um melhor desempenho, YMMV e alguns (ou todos) destes podem não se aplicar à sua situação.

Determine quanto você precisa para aumentar buffers/caches, observando a saída de um comando sql "show status" - existem ferramentas que podem ser úteis, muitas vezes eu uso apenas o phpmyadmin para ter uma idéia. http://blog.mysqltuner.com/ é um recurso útil e utilitário também.

Verifique se o cache de consulta está ativado e se ele é grande o suficiente para ter um número muito baixo de punes de pouca memória. Certifique-se de que o número de leituras de chave não seja muito alto (sendo este um valor relativo), aumentando key_buffer_size para ajudar com isso. Certifique-se de que o número de tabelas temporárias que estão sendo criadas é baixo, reduza esse número aumentando o tmp_table_size.

Ative o log de consultas lentas e registre consultas lentas, execute novamente essas consultas manualmente com instruções explain, inclua índices, altere os tipos de coluna, etc, conforme necessário. Para uma consulta, estávamos obtendo instruções de explicação insana (como na comparação de muitas mais linhas do que "deveria" ter sido), atualizar para uma versão mais nova do MySQL fez com que a mesma consulta fosse muito melhor otimizada (e muito mais rápida) pelo MySQL em si.

Se você estiver usando indexação de texto completo, não acredito que as tabelas InnoDB sejam uma opção - apenas não atualize produtos durante seus horários de pico. Se seu pacote de comércio eletrônico oferecer suporte, você poderá minimizar a interrupção do cliente (desempenho ou não) fazendo alterações no servidor de temporariedade e, em seguida, movendo apenas as tabelas de produtos com um despejo do estágio e carregando na produção - isso não trabalho sem algum trabalho adicional para o resto da sua instalação do Wordpress no entanto.

Se o design do seu site e o UX puderem ajudá-lo a orientar os usuários para um modo de "navegação" versus um modo de "pesquisa" (por exemplo: clicar em um site versus digitar pesquisas na caixa de pesquisa) podem ajudá-lo a tirar proveito de um banco de dados muito fácil nível e cache de nível Wordpress.

Pré-carregue seus caches - cache fácil como caches de consulta e cache no nível do Wordpress também podem ser pré-carregados com o wget. Você também pode pré-carregar o cache para pesquisas usando o comportamento de pesquisa do usuário (por meio de seus logs) e recuperando essas solicitações quando precisar preencher os caches.

11
bsr

Fiquei curioso sobre o meu próprio comentário e tenho feito algumas leituras, aqui é onde eu estou.

Primeiro, eu daria W3 Total Cache uma tentativa. Além disso, instale a extensão APC PHP no seu servidor e configure o W3 Total Cache para usá-lo. Ele usará o APC para armazenar em cache objetos de banco de dados, PHP e até mesmo ajuda a reduzir o seu CSS e JS. Pode fornecer o suficiente. Especialmente se você já incorporar algum cache MySQL. O W3 Total Cache também pode funcionar com o Memcache como um back-end de armazenamento em cache.

Para o banco de dados, armazena em cache as consultas é muito útil. Eu encontrei este link e ele explica como ele fez algumas coisas para o seu blog MU. Citar:

O Query Cache é um pequeno recurso no MySQL, onde armazena - em um dedicado estão dentro da memória principal - qualquer resultado de uma consulta para uma tabela que não tenha sido modificada recentemente.

Ou seja, supondo que uma solicitação chegue para recuperar uma linha específica em uma tabela - e essa tabela não tenha sido modificada recentemente de qualquer forma - e o cache não tenha preenchido exigindo limpeza/limpeza - a consulta/dados pode ser satisfeita dessa cache. O principal benefício aqui, é claro, é satisfazer o pedido - o banco de dados não precisa ir ao disco (que geralmente é a parte mais lenta do sistema) e pode ser imediatamente atendido.

Então, isso é muito legal, e vai ajudar muito, já que os produtos em si não vão mudar muito. Outra coisa que o artigo menciona é certificar-se de que você tem muita memória para manter o banco de dados em Ram, isso ajudará a acelerar as consultas de forma dramática.

Ele também fala sobre os tipos de tabelas, e usando o MyISAM sobre o InnoDB para as tabelas somente leitura, enquanto este raciocínio é um pouco orientado para MU, pode ser útil.

Em relação à configuração dos índices. Se você tiver muitos deles, eles poderão reduzir as inserções e ocupar mais espaço em disco. Mas como não imagino uma grande quantidade de produtos sendo adicionados regularmente, acho que isso é aceitável. E com espaço em disco sendo barato ...

1
Ryan Gibbons