Quão bem o WordPress escala?

34

Com o novo WordPress e seus novos recursos, parece que o WordPress é capaz de muito mais do que um simples mecanismo de blog. Mas quão bem o WordPress escala sendo usado por dizer 10k - > 100 mil usuários por dia?

Com muitos usuários, uma grande parte dele será ter uma boa estratégia de cache, mas o quão bem o WordPress é desenvolvido para ajudar, tornando isso fácil e dando a você o controle que você precisa. Fx sendo capaz de armazenar em cache parte de uma página e apenas renderizar partes customizadas pelo usuário, suportar configuração do banco de dados master / slave e coisas assim?

    
por googletorp 01.09.2010 / 09:43

3 respostas

37

Evidentemente, nada é dimensionado, assim como os arquivos estáticos servidos por um servidor Web rápido e qualquer CMS que precise descobrir o que carregar e carregar não funcionará tão bem, WordPress ou outros. Um dos problemas é o número de consultas de banco de dados necessárias por solicitação de URL e minha experiência de 2 anos anteriores trabalhando exclusivamente com o Drupal e agora com mais de 2 anos com o WordPress é que o WordPress é muito melhor nesse departamento.

Dito isto, quase nada com qualquer poder vai escalar "out-of-the-box" ; é tudo sobre o que você pode fazer à medida que sua escalabilidade precisa crescer?

No limite inferior de "lotes de tráfego" existem excelentes plug-ins de armazenamento em cache e integrações com CDNs de baixo custo você pode fazer muito bem trabalho em um orçamento sem TI e baixo orçamento de hospedagem. Aqui estão algumas outras perguntas e amp; respostas para revisar:

Existem opções para criar perfis para identificar gargalos de desempenho :

Depois que os afunilamentos são identificados, é possível fazer otimização localizada com elementos como a API de transientes . Este Q & A fornece um exemplo que pode ser otimizado usando a API de transientes e mostra como:

Se você realmente deseja extrair as grandes armas , pode configurar Memcached , HyperDB , Nginx e / ou mais para acelerar as coisas (parece que o último está realmente evoluindo para obter uma incrível escalabilidade do WordPress):

E finalmente há webhosts com foco no WordPress, especializados em desempenho , como WP Engine , ZippyKid e outros:

Então a boa notícia é toda a escala muito bem ; a partir do final muito baixo de graça e facilidade, com complexidade técnica, e os custos crescem apenas à medida que o tráfego cresce significativamente. Comece pequeno com o WordPress e vai ser ótimo. Se o seu tráfego crescer e você estiver monetizando, mesmo que razoavelmente bem, você perceberá que o custo é muito grande se necessário.

Pelo menos IMO. :)

    
por MikeSchinkel 01.09.2010 / 11:52
4
  1. Não espere muito de hospedagem compartilhada - não culpe o WordPress por lentidão se você estiver em um host compartilhado. Hosts compartilhados podem empinar milhares de contas em um servidor. Assim, você pode passar o dia todo otimizando uma conta de US $ 10 / mês e isso não importa. Tenha cuidado com os chavões de marketing - só porque diz "nuvem" não significa que você não esteja compartilhando um servidor com 100 ou 1000 pessoas.

  2. Eu não acho que os plug-ins de cache sejam necessários neste momento. Se você olhar para o código-fonte do WP, já há um cache avançado embutido no núcleo. Um cache do cache do cache do cache - cuidado, isso pode ser contraproducente.

  3. A principal coisa que está atrasando você é as consultas lentas do MySQL e o WordPress pronto para uso não deve causar problemas aqui. No entanto, eu tive que "LIMIT" minhas consultas de comentários porque eu tinha mais de 50.000 comentários. (Isso já foi corrigido?) Além disso, se você estiver fazendo algo atípico (como milhares de categorias?), Isso também pode ser um problema.

  4. Eu uso um Linode 512 com NginX e "top" mostra PHP e NginX fazendo seu trabalho em menos de 1/100 de segundo por requisição. Quase todo o tempo da CPU está ligado ao MySQL. Você poderia servir 1 milhão de páginas por mês com um Linode de US $ 20, mas assim que você começar a adicionar plugins e fotos, eu acho que você vai precisar de um Linode de "1GB". Do meu ponto de vista, é praticamente linear: se as visualizações de página duplicarem, apenas o dobro do tamanho do seu Linode.

Disclaimer: Eu não trabalho no Linode.

Atualização (~ 2 anos depois) já que você quer armazenar em cache partes de uma página com PHP, aqui está uma solução simples que eu uso de maneira surpreendentemente rápida. Estou fazendo cache de várias partes / partes separadas por página em 1/100 de segundo. Parece que um ramdisk pode tornar isso ainda mais rápido, mas é muito rápido para as minhas necessidades:

$cache_file = "./cache/portion-1". $since; // maybe round() this $since timestamp
$cache_life = 1000; // seconds to keep this cached
$filemtime = filemtime($cache_file);  // returns FALSE if file does not exist
if (!$filemtime or (time() - $filemtime >= $cache_life)) {

    // heavy lifting starts
    $output = 'Heavy!';
    // heavy lifting ends

    if (!file_put_contents($cache_file,$output,LOCK_EX)) { echo 'error'; } // save the cache    
    echo $output;

} else { 

    // load from cache
    $output = file_get_contents($cache_file); 
    echo $output;        
} 
    
por PJ Brunet 24.02.2011 / 04:24
0

Em última análise, há três coisas que reduzem a velocidade do WordPress em escala, e elas se resumem a isso:

  • Hosting stack - você precisa de um bom host com o software mais recente - PHP 7, Nginx, Varnish, Redis, fail2ban e PerconaDB são todas boas escolhas
  • Nenhuma varredura de tabela - muitos plugins são escritos por codificadores amadores que nem sequer sabem o que é uma varredura de tabela. Duas coisas são necessárias para evitar varreduras de tabela - um índice utilizável e uma consulta escrita de forma que possa usar o índice
  • Não ou poucas consultas SQL dentro de loops PHP - alguns códigos de plugins foram claramente testados em sites minúsculos e, por um motivo ou outro, percorrerão todos os produtos do banco de dados e farão uma nova chamada SQL para cada produto / publicação. Você deseja, idealmente, menos de 100 consultas SQL por página - parece muito, mas não é realmente e com < 100 você obterá um TTFB de cerca de 200 ms sem cache.

Depois de definir o acima, você poderá adicionar o armazenamento em cache. Verniz, CDNs, cache de páginas, etc.

Se precisar expandir, você pode criar um cluster usando o PerconaDB XtraDB para o banco de dados e o Unison para os arquivos. Dessa forma, você pode ter 1 nó como seu wp-admin e cron runner, e os outros nós servindo o tráfego da web por trás de um balanceador de carga.

    
por Dave Hilditch 12.06.2017 / 20:35