Caching páginas PHP, Varnish, nginx, outro?

3

Eu tenho um aplicativo da web em execução em uma caixa baixa (1gb de RAM), que serve uma mistura de páginas estáticas e dinâmicas (php). Estas páginas PHP estão consultando um banco de dados MYSQL que não muda com frequência - uma vez por semana?.

Eu estou olhando para fazer uma boa quantidade de cache para manter tudo bom e rápido. Eu tenho páginas que embora sejam php, as informações raramente mudam (Obtendo uma lista de itens que podem mudar uma vez a cada poucos meses?). Algumas páginas podem listar até 400 registros.

Eu tenho Varnish, nginx, PHP-FPM, APC e MYSQL instalados. Eu acho que tenho tudo configurado corretamente. As páginas estão sendo exibidas e eu tenho hits aparecendo em verniz ... Brill! No entanto, devido à natureza do site, não tenho certeza de que ele esteja otimizado o máximo possível.

Uma pesquisa recente sugeriu várias coisas que podem ajudar com minhas páginas php:

  • cache de FastCGI nginx
  • memcached
  • Cache de consulta MYSQL

Um exemplo: uma nova página do PHP, onde está listando alguns (200+) registros: 2 segundos             Após uma atualização, 1,5 (ish) segundos. edit: Estou sendo irrealista para esperar que esta página seja armazenada em algum lugar ao longo da linha e seja fornecida muito mais rapidamente depois de ter sido visitada?

Qual seria minha melhor opção? Um ou todos os itens acima?

    
por Coffeee 04.10.2013 / 12:24

3 respostas

5

  • O Memcached requer que seu código realmente o use. Mas se você escreveu este código, então isso deve ser fácil de fazer:)
  • O cache do MySQL funciona até certo ponto. Idealmente, atualize para unidades SSD se ainda não.
  • Eu nunca ouvi falar do cache do FastCGI. Você está se referindo ao cache páginas dinâmicas como estáticas?

Honestamente, se você ajustou tudo o melhor que pode, eu consideraria atualizações de hardware. Se você tiver tempo, examine a pesquisa do Facebook como o HipHop ( link ). Eles fizeram pesquisas e desenvolvimentos incríveis para criar páginas dinâmicas com carregamento rápido.

Boa sorte!

    
por 04.10.2013 / 14:23
3

Cuidado com o cache de consultas do MySQL - ele usa um bloqueio global, então quando você começa a ter muita atividade, você verá deadlocks periódicos. O cache de consulta é útil somente para consultas exatamente as mesmas , e se você tiver muitas delas não está fazendo o cache em nível de aplicativo corretamente.

O primeiro passo para trabalhar no desempenho é sempre o perfil; otimização baseada na intuição é uma ótima maneira de desperdiçar seu tempo.

No trabalho, usamos Grafite como nosso repositório de dados, com uma versão modificada de StatsD e pipe-to-graphite como dados primários Métodos de envio. Ambas as ferramentas facilitam o envio de dados e, em seguida, o Graphite tem uma infinidade de ferramentas de análise.

Por exemplo, usando o script de verniz de pipe para grafite , pegamos todas as estatísticas de varnishstats . Isso nos permite fazer facilmente gráficos de acerto / erro no Graphite, assim:

Vocêpodefazeramesmacoisacomomemcachedeadicionarganchosemseupróprioaplicativoparagravar...bem,tudoequalquercoisa!

Vocêtambémpodeencontrarferramentasdeanálisedepáginaúnicacomo xhprof e YSlow útil.

Depois de ter métricas, você não só sabe o que deve estar trabalhando, mas também poderá medir a melhoria quando terminar. Todo mundo gosta de validação!

    
por 05.10.2013 / 04:25
3

quando você não precisa de recursos especiais do verniz, pode soltá-lo e usar o fastcgi_cache do nginx. mas cuidado, ao contrário do proxy_cache, você pode ter apenas 1 cache_zone em toda a sua configuração.

talvez sua configuração seja um pouco otimizada ... Eu pensaria em usar apenas nginx ou verniz.

quando se trata de memcache: dependendo de quantas requisições / segundo você tiver, o memc pode ser um verdadeiro impulso, mas talvez não seja necessário no seu caso. Quando você tem um bom cache frontal, não precisa ativar o Memcache, mas o YMMV. o que entendi: você entrega páginas que não são alteradas com frequência, né?

Sempre tento otimizar da seguinte maneira:

  1. tente evitar que as solicitações sejam respondidas pela sua pilha de aplicativos - > interceptar solicitações por cache frontenend (nginx / verniz) e servidor estático, onde possível
  2. se php, use um cache opcode como o APC
  3. ajustar seu db
  4. monitore seu sistema (carregar, mem, ram, netio, hdio, netconns, netconns: http, site_stats)
  5. repetir a sintonização
por 05.10.2013 / 12:00