Temos um site em um servidor dedicado. Aqui estão as configurações do servidor:
- GenuínoIntel, Intel (R) Core (TM) i5-2400[e-mail protegido]
- Versão Plesk v10.3.0_build1012110629.18 os_Ubuntu 10.04
- SO Linux 2.6.38.2-xxxx-std-ipv6-64
- Memória Total 16Gb
Esse site (http://www.bobcat.pro) é um site de comércio eletrônico composto por 18.000 categorias e 300.000 produtos. Tudo rodando em PHP5/MySQL.
Como você pode perceber durante a navegação, a exibição das páginas é feita em 5 segundos (ou mais) o que é muito longo. Estou procurando uma forma de reduzir a exibição que seja compatível com a instalação do nosso servidor.
Usei verniz, mas tive muitos problemas com a experiência para tentar novamente. O que você recomenda? O módulo page_speed google para apache 2 é uma boa solução?
Responder1
O verniz é provavelmente a solução certa para você. No entanto, você também pode prosseguir com outras coisas.
Tente usar um dos seguintes:
Essas soluções acelerariam o acesso de backup para o seu processo Apache e removeriam a sobrecarga de acesso ao banco de dados para páginas.
No entanto, eu ainda recomendo que você poste uma pergunta sobre quais problemas você enfrentou ao implementar o verniz, talvez eles sejam resolvidos, já que o verniz geralmente funciona muito bem para a maioria das pessoas.
Responder2
Os fornecedores do aplicativo de comércio eletrônico poderiam responder melhor.
À primeira vista, parece que ele deseja algum tipo de cabeçalho de controle de cache nas respostas HTTP - um cabeçalho 'Expires' ou um 'Etag'. No entanto, você não deseja necessariamente adicioná-los em todos os lugares, ou então você pode quebrar algo onde o usuário realmente precisa de uma nova visão em vez de ir para um cache.
Na verdade, é meio criminoso que o aplicativo de comércio eletrônico não ajuste esses cabeçalhos imediatamente (saber quando o cache está 'obsoleto' é algo que o aplicativo conhece melhor). Eu estaria procurando por um diferente.
Além disso, a julgar pelo tempo necessário para uma única solicitação, parece que o aplicativo não está preparado para o número de categorias e produtos que você está infligindo a ele. Eles provavelmente fazem algumas consultas SQL que envolvem 'varreduras de tabela' (muitas E/S de disco) ou, alternativamente, algumas consultas complexas que envolvem conjuntos de trabalho muito grandes na memória do banco de dados (por exemplo, classificação de 300.000 registros). Os índices no banco de dados MySQL às vezes podem ajudar com esses problemas, mas, novamente, seria melhor se o procedimento de instalação do aplicativo os adicionasse, já que primeiro é necessário saber quais consultas o aplicativo provavelmente emitirá antes de poder otimizar o banco de dados para elas. Outro sinal de que você tem o aplicativo de comércio eletrônico errado para o trabalho.