Qual é a escala do WordPress?

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 a escala do WordPress está sendo usada por, digamos, 10.000 a 100.000 usuários por dia?

Com tantos usuários, grande parte disso será ter uma boa estratégia de cache, mas quão bem o WordPress é desenvolvido para ajudar, facilitando isso e fornecendo o controle de que você precisa. Ser capaz de armazenar em cache parte de uma página e renderizar apenas peças personalizadas do usuário, suporta a configuração master / slave db e coisas assim?

Claramente, nada é dimensionado, assim como os arquivos estáticos servidos por um servidor da Web rápido e qualquer CMS que precise descobrir o que carregar e depois carregá-lo não terá um desempenho tão bom, WordPress ou outro. Um dos problemas é o número de consultas ao banco de dados necessárias por solicitação de URL e meus 2 anos anteriores de experiência trabalhando exclusivamente com o Drupal e agora mais de 2 anos com o WordPress são que o WordPress é muito melhor nesse departamento.

Dito isto, quase nada com qualquer poder vai escalar "fora da caixa" ; é tudo o que você pode fazer à medida que suas necessidades de escalabilidade aumentam?

Na extremidade baixa de "muito tráfego", existem ótimos plug - ins de cache e integrações com CDNs baratas, você pode fazer um bom trabalho com um orçamento sem TI e baixo orçamento de hospedagem. Aqui estão algumas outras perguntas e respostas para revisão:

• Etapas para otimizar o WordPress em relação à carga do servidor?
• Opções para CDN com WordPress, incluindo plugins de suporte?
• Configurando o WordPress para armazenamento em cache do Amazon CloudFront?

Existem opções para criação de perfil para identificar gargalos de desempenho :

• Criar um perfil de um site WordPress para implantação em hospedagem compartilhada?

Depois que os gargalos são identificados, você pode fazer a otimização localizada com coisas como a API de transientes . Estas perguntas e respostas fornecem um exemplo que pode ser otimizado usando a API Transients e mostra como:

• Usando WP_Query para consultar várias categorias com postagens limitadas por categoria?

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

• Habilite o Memcached para seu WordPress
• Como acelerar o WordPress com Nginx e WP Super Cache
• HyperDB
• Nginx como um cache proxy de front-end para WordPress

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

• Os melhores recursos de um host WordPress de ponta?

Portanto, as boas notícias são todas as escalas muito bem ; desde o nível mais baixo de graça e fácil, com complexidade e custo técnicos, apenas aumentam à medida que o tráfego aumenta significativamente. Comece pequeno com o WordPress e será ótimo. Se o seu tráfego aumentar e você estiver rentabilizando-o razoavelmente bem, você encontrará um efeito de custo muito escalável conforme necessário.

Pelo menos IMO. :)

1. Não espere muito da hospedagem compartilhada - não culpe o WordPress pela lentidão se você estiver em um host compartilhado. Hosts compartilhados podem amontoar 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. Também preste atenção às palavras-chave de marketing - apenas porque diz "nuvem" não significa que você não esteja compartilhando um servidor com centenas ou milhares de pessoas.

2. Eu não acho que plugins de cache sejam necessários neste momento. Se você olhar o código fonte do WP, já existe um cache avançado incorporado ao núcleo. Um cache do cache do cache do cache - cuidado, isso pode ser contraproducente.

3. A principal coisa que atrasa você é a lenta consulta ao MySQL e o WordPress pronto para uso não deve causar problemas aqui. No entanto, tive que "LIMITAR" minhas consultas de comentários porque 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 solicitação. Quase todo o tempo da CPU está relacionado ao MySQL. Você pode servir 1 milhão de páginas por mês com um Linode de US $ 20, mas assim que começar a adicionar plugins e fotos, acho que precisará de um Linode de "1 GB". Do meu ponto de vista, é praticamente linear: se as visualizações de página dobrarem, apenas o dobro do tamanho do seu Linode.

Disclaimer: Eu não trabalho para Linode.

Atualize (~ 2 anos depois), uma vez que você deseja armazenar em cache partes de uma página com PHP, aqui está uma solução simples que eu uso que é surpreendentemente rápida. Estou armazenando em cache várias partes / partes separadas por página dentro de 1/100 de segundo. Parece que um ramdisk poderia tornar isso ainda mais rápido, mas é muito rápido para 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;        
} 

Existem três coisas que diminuem a velocidade do WordPress em escala, e elas se resumem a isso:

• Pilha de hospedagem - 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 sabem o que é uma varredura de tabela. São necessárias duas coisas para evitar varreduras de tabela - um índice utilizável e uma consulta escrita de forma que ele possa usar o índice
• Nenhuma ou poucas consultas SQL dentro de loops PHP - alguns códigos de plug-in foram claramente testados apenas em sites pequenos 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. Idealmente, você deseja menos de 100 consultas SQL por página - parece muito, mas não é verdade e, com <100, você obterá um TTFB de cerca de 200 ms sem cache.

Depois de colocar o que foi dito acima, você poderá adicionar o cache - por exemplo, verniz, CDNs, cache de página 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 que atendem ao tráfego da web atrás de um balanceador de carga.