Uma olhada na pilha de servidores WordPress moderna

Você se lembra de quando podia executar um site WordPress “rápido” com apenas um servidor Apache e PHP? Sim, aqueles foram os dias! As coisas eram muito menos complicadas naquela época.

Agora, tudo tem que carregar rápido como um raio! Os visitantes não têm as mesmas expectativas sobre os tempos de carregamento que costumavam ter. Um site lento pode ter sérias implicações para você ou seu cliente.

Leitura adicional no SmashingMag:

• Permissões e propriedades adequadas do sistema de arquivos WordPress
• Movendo um site WordPress sem complicações
• Como desenvolver o WordPress localmente com MAMP
• Métodos de armazenamento em cache do tipo faça você mesmo com o WordPress

Consequentemente, a pilha de servidores WordPress teve que evoluir ao longo dos anos para acompanhar essa necessidade de velocidade. Como parte dessa evolução, algumas marchas tiveram que ser adicionadas ao seu motor. Algumas das engrenagens mais antigas tiveram que mudar também.

O resultado é que a pilha de servidores do WordPress parece bem diferente hoje do que há alguns anos. Para entender melhor, vamos explorar essa nova pilha em detalhes. Você verá como as várias peças se encaixam para tornar um site WordPress rápido.

Visão geral

Antes de mergulhar, vamos diminuir o zoom e olhar para o quadro geral. Como é essa nova pilha de servidores WordPress? Bem, aqui está a resposta:

O diagrama acima fornece uma boa visão geral de como é a pilha de servidores WordPress moderna. Em um nível alto, podemos dividir o que está acontecendo em três áreas:

• o ciclo de solicitação-resposta entre o navegador e o WordPress;
• WordPress (que é um script que o runtime do PHP executa);
• o ciclo do resultado da consulta entre o WordPress e o banco de dados MySQL.

O papel da pilha de servidores WordPress moderna é otimizar essas três áreas. Essas otimizações são o que fazem tudo carregar mais rápido. E a melhor parte é que existem várias maneiras de fazer isso. (Yay!)

Na maioria dos casos, essas otimizações envolvem a instalação de novos serviços em seu servidor. Às vezes, esses serviços precisarão da ajuda de um plugin para interagir com o WordPress. Também haverá momentos em que você poderá se safar apenas instalando um plug-in. Você verá muitas opções diferentes ao longo deste artigo.

O ciclo de solicitação-resposta

Tudo começa com o navegador. Digamos que você queira ver a página inicial do modern.wordpress-stack.org . Seu navegador começará enviando uma solicitação HTTP para o servidor web que o hospeda. Na outra extremidade, o servidor da Web receberá sua solicitação e a transformará em uma resposta HTTP.

Essa primeira resposta deve ser sempre o conteúdo HTML da página inicial do modern.wordpress-stack.org (a menos que haja um erro). No entanto, o trabalho do seu navegador não está feito. Não, essa home page ainda precisa de mais arquivos, sendo os mais comuns arquivos CSS, JavaScript e imagens.

Assim, o navegador enviará solicitações para esses arquivos. O servidor web responderá com os arquivos solicitados (novamente, desde que não haja erros). Esse ciclo continuará até que o navegador tenha informações suficientes para renderizar a página inicial. Quanto mais rápido esse ciclo acontecer, mais rápido o site parecerá carregar.

Agora, esta é uma simplificação óbvia, mas é assim que as coisas funcionam para a maioria dos sites WordPress.

Otimizando o ciclo de solicitação-resposta

Tudo bem, isso nos leva à pergunta óbvia, como podemos fazer um servidor web executar esse ciclo mais rápido? Esta é uma ótima pergunta e é parte da razão pela qual a pilha de servidores WordPress moderna existe.

A pilha existe porque você não pode simplesmente tornar um servidor web mais rápido. Um servidor web também é um despachante. Ele pode receber uma solicitação e apenas encaminhá-la para outros serviços.

Esses outros serviços costumam ser o gargalo desse ciclo de solicitação-resposta. Com o WordPress, esse gargalo é o PHP, e é por isso que otimizar o ciclo de solicitação-resposta se resume a duas coisas. Queremos que o servidor web:

• receber o menor número de solicitações possível,
• encaminhar o menor número possível de solicitações para o PHP.

A pilha de servidores WordPress moderna se concentra neste último. Ele quer encaminhar o menor número possível de solicitações ao PHP. Esse será o objetivo principal para otimizar a pilha.

Nós nos concentramos no segundo objetivo porque a pilha não pode fazer muito sobre o primeiro; não tem impacto direto sobre ele. A segunda é abordada pela configuração do servidor web ou por técnicas modernas de desenvolvimento.

Elementos de pilha para o ciclo de solicitação-resposta

Então, quais são os elementos da pilha que nos ajudarão a reduzir as requisições encaminhadas ao PHP? Bem, dois elementos de pilha em particular nos ajudarão a atingir esse objetivo: o servidor web e o cache HTTP.

Servidor web

Já falamos bastante sobre servidores web. Existem três grandes players no espaço do servidor web:

• Apache
• Serviços de Informações da Internet (IIS)
• nginx

Juntos, eles representam mais de 90% da participação de mercado de servidores web na Internet. Vamos nos concentrar no Apache e no nginx. Embora o IIS possa ser usado para executar o WordPress, não é comum porque está disponível apenas para Windows, e a maioria dos servidores WordPress usa Linux.

Isso nos deixa com Apache e nginx. Por toda a vida do WordPress, o Apache tem sido o servidor web recomendado. Tínhamos a pilha LAMP (Linux, Apache, MySQL e PHP), que rodava o WordPress tanto no computador quanto no servidor.

Mas nos bastidores, as coisas estavam mudando. Havia um novo jogador na cidade, e seu nome era nginx. Automattic e WordPress.com o utilizam desde 2008. É o servidor web que executa a maior porcentagem de sites de alto tráfego (muitos dos quais executam o WordPress). É por isso que muitas empresas de hospedagem de ponta e as principais agências do WordPress o usam como servidor da web.

Não é que o Apache seja um servidor web ruim. Existem especialistas em Apache que podem fazê-lo funcionar muito bem com muito tráfego. Ele simplesmente não funciona tão bem fora da caixa ou com a configuração padrão do WordPress.

Enquanto isso, o único propósito do nginx é lidar com muito tráfego. É por isso que Igor Sysoev iniciou o projeto quando trabalhava na Rambler.

Uma das razões pelas quais o nginx lida melhor com mais tráfego é que ele usa FastCGI para se comunicar com o PHP. O que é FastCGI? É um protocolo que permite que o PHP seja executado como um serviço separado do servidor web.

O Apache não faz isso por padrão. Cada vez que o servidor web recebe uma solicitação, ele precisa iniciar um processo de execução do PHP — mesmo para imagens, JavaScript e CSS. Isso reduz o número de solicitações que o servidor pode manipular e a rapidez com que ele pode lidar com elas.

Isso vai contra um dos objetivos da pilha de servidores WordPress moderna, que vimos anteriormente. A pilha precisa manter o tempo de ciclo de solicitação-resposta o mais baixo possível. Carregar PHP para cada solicitação, mesmo quando não precisa, vai contra esse objetivo. Então, se você usa Apache, procure FastCGI.

HTTP/2 é outro recurso importante do servidor web que você deve conhecer. É a próxima versão do HTTP, o protocolo que alimenta todo o nosso ciclo de solicitação-resposta.

Antes da chegada do HTTP/2, um navegador podia ter apenas seis conexões com o servidor web. E cada conexão poderia lidar com apenas uma solicitação por vez. Assim, na prática, um ciclo de solicitação-resposta foi limitado a seis solicitações por ciclo.

Isso é um problema real. A maioria dos sites tem dezenas de solicitações em seu ciclo. Desenvolvedores e administradores de sistema encontraram maneiras inteligentes de contornar essa limitação.

Uma das soluções mais conhecidas é a prática de combinar arquivos CSS e JavaScript. Em um cenário ideal, isso reduziria o número total de solicitações de arquivos CSS e JavaScript para dois: um para JavaScript e outro para CSS.

Isso não é necessário com HTTP/2. HTTP/2 permite um número ilimitado de solicitações por conexão. Isso permite que todas as solicitações extras após a resposta HTML inicial ocorram ao mesmo tempo.

Isso tem enormes implicações de desempenho. Muito do trabalho de otimização da pilha de servidores está centrado no ciclo de solicitação-resposta. Ao reduzir o número de ciclos para apenas um punhado, o HTTP/2 fez um tremendo trabalho para nós.

Cache HTTP

A parte mais importante da pilha de servidores WordPress moderna é o cache HTTP. No mundo WordPress, também chamamos isso de cache de página. A finalidade do cache HTTP é armazenar em cache as respostas às solicitações. O que isto significa?

Bem, vamos voltar ao nosso exemplo anterior. O navegador envia uma solicitação para a página inicial de modern.wordpress-stack.org e o servidor da Web recebe essa solicitação e a encaminha para o PHP.

O problema com este cenário é que o servidor web é burro. Ele sempre encaminhará todas as solicitações recebidas para o PHP — independentemente de a maioria das solicitações gerarem a mesma resposta.

Isso é exatamente o que acontece quando os visitantes não estão logados. Para o servidor web, são todas solicitações diferentes, mas isso não importa. Ele irá encaminhá-los todos para o PHP, que irá gerar a mesma resposta para todos eles.

Isso é terrível! Como vimos anteriormente, o PHP é o verdadeiro gargalo do nosso ciclo de solicitação-resposta. Seu navegador não pode enviar suas solicitações de acompanhamento até receber a resposta inicial da página inicial. Não podemos fazer com que o servidor web encaminhe tudo para o PHP por padrão.

É aí que entra o cache HTTP. Ele fica entre o servidor web e o PHP. Seu trabalho é verificar todas as solicitações que o servidor da Web recebe e procurar uma resposta em cache. Se não houver nenhum, ele encaminhará a solicitação para o PHP e, em seguida, armazenará em cache a resposta que o PHP gera.

Isso reduz drasticamente o tempo do ciclo de solicitação-resposta, tornando o carregamento do site mais rápido. Ele também permite que o servidor da Web lide com mais solicitações simultâneas sem explodir.

Os diferentes sabores do cache HTTP

Neste ponto, você deve estar se perguntando: “Como posso colocar esse bebê no meu servidor o mais rápido possível?!” A boa notícia é que instalar um cache HTTP em um servidor WordPress é bastante fácil. É o componente com a maior variedade de opções.

Instale um plug-in de cache de página

A maneira mais fácil é instalar um plugin de cache de página. Você tem algumas opções para escolher:

• Batcache
• Hipercache
• Ativador de cache
• WP Foguete
• Supercache WP
• Cache Total W3

Todos, exceto o WP Rocket, estão disponíveis como plugins gratuitos no diretório do WordPress. Assim, você pode instalar um e testá-lo imediatamente. Dito isto, dos quatro plugins, o melhor é o WP Rocket. Embora seja um plugin pago, ele faz muito mais do que apenas criar um cache HTTP. Esses outros benefícios ampliam o trabalho que o cache HTTP está fazendo.

Como funciona um plug-in de cache de página?

Todos esses plugins aproveitam um drop-in que o WordPress disponibilizou para armazenamento em cache. Este drop-in de cache permite que os plugins criem um sistema de cache HTTP dentro do WordPress. O drop-in de cache precisa de duas coisas para funcionar.

Primeiro, o arquivo drop-in advanced-cache.php precisa estar na pasta wp-content . Esse é o arquivo real. Mas, ao contrário da maioria dos drop-ins do WordPress, este não é ativado por padrão. O WordPress também precisa que a constante WP_CACHE seja true para carregar o drop-in. Na maioria dos casos, você definiria isso em wp-config.php .

O diagrama acima mostra o que acontece quando você ativa o drop-in com um plug-in de cache. O WordPress carrega o drop-in em wp-settings.php durante o processo de carregamento. Isso é cedo o suficiente no processo para que o WordPress ainda não tenha feito nada demorado.

O plug-in de cache verificará se já armazenou em cache a resposta à solicitação. Se tiver, ele retornará essa resposta em cache. Se não tiver, ele ativará o buffer de saída do PHP e o WordPress continuará carregando.

Agora, o buffer de saída é um sistema interessante. O que ele faz é capturar toda a saída de um script PHP em uma variável de string até que uma das duas coisas aconteça:

• você diz ao PHP para parar de armazenar em buffer sua saída usando uma das funções internas,
• o script PHP termina e precisa retornar uma resposta ao navegador.

O plugin de cache está contando com o último cenário. Ele quer que o WordPress faça seu trabalho e, em seguida, armazene em cache toda a saída antes que o PHP a envie de volta ao navegador. Você pode ver o processo no diagrama abaixo.

Faça com que o servidor da Web faça isso

A próxima opção é adicionar um cache HTTP no nível do servidor web. A maneira como funciona é que o servidor da web armazenará em cache todas as respostas às solicitações que são encaminhadas ao PHP. Esta solução é melhor do que um plugin de cache porque não precisa tocar em PHP.

O diagrama acima fornece uma visão geral do que está acontecendo no servidor web. O servidor web recebe uma solicitação e verifica com o cache HTTP. Se uma resposta já tiver sido armazenada em cache, o cache HTTP a enviará de volta.

Caso contrário, ele encaminhará a solicitação para o módulo PHP (geralmente FastCGI). Ele passará a solicitação para o WordPress para que ele possa gerar uma resposta. O módulo de cache HTTP armazenará em cache essa resposta no caminho de volta.

Tanto o Apache quanto o nginx vêm com a capacidade de adicionar um sistema de cache HTTP. O nginx está embutido. O Apache é um módulo separado que você precisa adicionar à sua instalação do Apache.

Não há muitas informações sobre como usar o módulo Apache com PHP ou WordPress. Isso pode ser porque não é popular entre o público do Apache, ou talvez porque tenha alguns problemas. Há pelo menos um problema de longa data com ele que ainda está em aberto.

Enquanto isso, o sistema de cache HTTP nginx é robusto e bem documentado. Você pode usá-lo como um cache HTTP normal ou como um micro-cache menor, porém eficaz. É apenas mais uma razão pela qual o nginx é o servidor web preferido hoje em dia.

Adicionar verniz à pilha

O que é verniz? É um servidor de cache HTTP dedicado (ou, como seus desenvolvedores gostam de chamá-lo, acelerador HTTP). A maioria dos sites de alto tráfego e empresas de hospedagem premium o usam como sua solução de cache HTTP.

Eles o usam porque é poderoso e oferece mais flexibilidade. O verniz possui sua própria linguagem de configuração, chamada VCL. Ele permite que você controle todos os elementos do processo de armazenamento em cache. O Varnish também vem com muitas ferramentas para analisar o que o cache está fazendo e como está funcionando.

Essas são as principais diferenças entre usá-lo e apenas usar o cache HTTP do servidor web integrado. O cache HTTP do servidor web integrado é super-desempenhado, mas também bastante básico. Você não tem muito controle além de algumas opções de configuração.

No entanto, esse poder e flexibilidade têm um preço. O verniz também é a opção de cache HTTP mais complicada. Ele não faz nada além de armazenar em cache as respostas HTTP. Ele não lida com a terminação SSL, o que a maioria dos desenvolvedores do WordPress deseja (ou deveria querer). Isso significa que nossa pilha de servidores WordPress moderna será mais complexa quando a usarmos.

O diagrama acima ilustra essa complexidade extra. Agora temos mais dois componentes em nossa pilha de servidores WordPress: Varnish e um proxy reverso.

O proxy reverso existe para superar a limitação que o Varnish tem com SSL. Ele fica na frente do Varnish e descriptografa as solicitações que nosso servidor recebe. Você também pode chamar esse tipo de proxy reverso de proxy de terminação SSL. O proxy então envia essas solicitações descriptografadas ao Varnish para processar.

Assim que uma solicitação chega ao Varnish, o(s) arquivo(s) de configuração da VCL entra em ação. Eles são o cérebro do Varnish. Por exemplo, eles dizem como:

• analisar, limpar e modificar solicitações recebidas;
• procure uma resposta em cache;
• analisar, limpar e modificar as respostas de retorno do WordPress;
• armazenar em cache essas respostas de retorno;
• manipular uma solicitação para remover uma ou mais respostas do cache.

Este último é especialmente importante. Deixado por conta própria, o Varnish não tem como saber quando o WordPress deseja remover uma página do cache. Portanto, por padrão, se você fizer alterações em uma postagem e atualizá-la, os visitantes continuarão vendo a mesma página em cache. Para nossa sorte, existe um plugin que remove as páginas do cache do Varnish.

WordPress

Tudo bem, nosso pedido para a home page do modern.wordpress-stack.org chegou ao WordPress. Ele passou pelo ciclo de solicitação-resposta que acabamos de abordar. O cache HTTP fez todo o possível para encontrar uma resposta HTTP para enviar de volta.

Mas não havia resposta HTTP em cache para enviar de volta ao navegador. Nesse ponto, o cache HTTP não tinha outra escolha. Ele teve que encaminhar a solicitação HTTP para o WordPress.

Está tudo nas mãos do WordPress agora. O WordPress precisa transformar nossa solicitação HTTP em uma resposta HTTP e enviá-la de volta ao cache HTTP. Como vimos anteriormente, este é o principal gargalo de toda a nossa moderna pilha de servidores WordPress.

A causa desse gargalo é dupla. WordPress tem muito código PHP para executar. Isso é demorado, e quanto mais lento o PHP estiver fazendo, mais tempo levará.

O outro gargalo são as consultas ao banco de dados que o WordPress precisa realizar. As consultas de banco de dados são operações caras. Quanto mais houver, mais lento o WordPress fica. Este será o foco da última seção sobre o ciclo do resultado da consulta.

Otimizando o tempo de execução do PHP

Vamos voltar ao PHP. Neste momento, o WordPress tem um requisito mínimo de PHP 5.2. Esta versão do PHP tem quase 10 anos! (A equipe do PHP parou de apoiá-lo em 2011.)

A equipe do PHP não ficou parada todos esses anos. Inúmeras melhorias de desempenho foram feitas, especialmente nos últimos anos. Vejamos o que você pode fazer para otimizá-lo hoje em dia.

Use a última versão do PHP

A coisa mais fácil que você pode fazer é atualizar sua versão do PHP. As versões 5.4, 5.5 e 5.6 tiveram melhorias de desempenho. A maior melhora foi de 5,3 para 5,4. Mudar para ele aumentou o desempenho do WordPress em uma quantidade decente.

Instalar o cache de Opcode

O cache de Opcode é outra maneira de acelerar o PHP. Como uma linguagem de script do lado do servidor, o PHP tem uma grande falha: ele precisa compilar um script PHP toda vez que o executa.

A solução para este problema é armazenar em cache o código PHP compilado. Dessa forma, o PHP não precisa compilá-lo toda vez que o executa. Este é o trabalho do cache de opcode.

Antes do PHP 5.5, o PHP não vinha com um cache opcode. Você teve que instalá-lo sozinho no servidor. Esta é outra razão pela qual usar uma versão mais recente do PHP é melhor.

Mudar para um compilador de última geração

A última coisa que você pode fazer é mudar para um dos dois compiladores de última geração: o HHVM do Facebook ou o PHP 7, a versão mais recente do PHP. (Por que PHP 7? É uma longa história.)

O Facebook e a equipe do PHP construíram esses dois compiladores do zero. Eles queriam alavancar estratégias de compilação mais modernas. HHVM usa compilação just-in-time, enquanto PHP 7 usa compilação antecipada. Ambos oferecem melhorias de desempenho incríveis em relação ao bom e velho PHP 5.

HHVM foi o primeiro a entrar em cena há alguns anos. Muitos hosts de primeira linha tiveram muito sucesso com ele, oferecendo-o como seu principal compilador PHP.

Vale ressaltar, porém, que o HHVM não é um compilador oficial de PHP. Não é 100% compatível com PHP. A razão é que o HHVM não foi projetado apenas para suportar PHP; é também um compilador para a linguagem de programação Hack do Facebook.

PHP 7 é um compilador PHP oficial. Não existe há muito tempo. A equipe do PHP o lançou em dezembro de 2015. Isso não impediu que algumas empresas de hospedagem WordPress já o suportassem.

A boa notícia é que o próprio WordPress é 100% compatível com ambos os compiladores! A má notícia é que nem todos os plugins e temas são, porque a versão mínima do PHP para WordPress ainda é 5.2.

Nada está forçando os autores a fazer seus plugins ou temas funcionarem com esses compiladores. Então, você não pode ir all in com um deles. Sua pilha deve sempre retornar ao PHP 5.

Ciclo de consulta-resultado

Neste ponto, o tempo de execução do PHP está passando por todos os arquivos PHP do WordPress e os executando. No entanto, esses arquivos PHP do WordPress não contêm nenhum dado. Eles contêm apenas o código do WordPress.

O problema é que o WordPress armazena todos os seus dados em um banco de dados MySQL. Então, para chegar a isso, o tempo de execução do PHP precisa consultar esse banco de dados. O servidor MySQL retorna o resultado dessa consulta, e o tempo de execução do PHP continua a executar os arquivos PHP do WordPress… bem, isto é, até precisar de dados novamente.

Esse vai e vem pode acontecer de algumas dezenas de vezes a algumas centenas de vezes. (Você pode querer falar com seu desenvolvedor se for o último!) É por isso que é um grande gargalo.

Otimizando o Ciclo da Consulta-Resultado

O objetivo de otimização aqui é acelerar o tempo de execução dos arquivos do WordPress por PHP. É aqui que as consultas de banco de dados são problemáticas. Eles tendem a levar mais tempo do que apenas executar um código PHP simples (a menos que seu código esteja fazendo algo ultrajante).

A maneira óbvia de corrigir esse problema é reduzir o número de consultas que o WordPress precisa realizar. E isso sempre vale a pena! Mas não é algo que a pilha de servidores WordPress moderna possa ajudar.

Podemos não conseguir reduzir o número de consultas que o WordPress faz, mas também não estamos sem opções. Ainda há duas maneiras pelas quais a pilha pode nos ajudar a otimizar o ciclo do resultado da consulta. Ele pode reduzir o número de consultas feitas ao banco de dados em primeiro lugar. E para as consultas que chegam ao banco de dados, pode diminuir o tempo necessário para executá-las.

Essas duas opções são feitas para fazer a mesma coisa: fazer o PHP esperar o mínimo possível pelos resultados do banco de dados, o que tornará o próprio WordPress mais rápido.

Elementos de pilha para o ciclo de resultado da consulta

Vejamos os diferentes elementos da pilha envolvidos no ciclo do resultado da consulta. Esta parte da pilha é menos complexa. Mas ainda envolve mais de um componente – ou seja, o servidor de banco de dados MySQL e o cache de objetos.

Servidor de banco de dados MySQL

Alguns anos atrás, um servidor de banco de dados MySQL significaria a mesma coisa para todos. Era um servidor com o servidor MySQL instalado. Mas as coisas mudaram muito nos últimos anos.

Vários grupos não estavam satisfeitos com a forma como a Oracle estava gerenciando o projeto MySQL. Então, cada grupo fez um fork e criou sua própria versão que você poderia “acessar” em vez disso. O resultado é que agora existem vários servidores de banco de dados MySQL.

O novo servidor MySQL “oficial” é o servidor MariaDB. É a versão desenvolvida pela comunidade do servidor MySQL. A comunidade planeja manter total compatibilidade com o projeto do servidor MySQL.

Outra alternativa popular ao MySQL é o servidor Percona. Ao contrário do MariaDB, o Percona é mais um ramo do MySQL. Seus desenvolvedores não são contra o projeto MySQL em si; eles só querem se concentrar em melhorar o desempenho do MySQL. Mais tarde, a equipe do MariaDB combinou algumas dessas melhorias de desempenho no projeto MariaDB.

No final do dia, você pode escolher o que preferir. Não há diferença de desempenho entre um servidor Percona e um servidor MariaDB (para a maioria de nós, de qualquer forma). Ambos funcionam melhor que o MySQL. Percona, no entanto, mantém uma maior compatibilidade com o projeto Oracle.

O que afeta o desempenho é o mecanismo de armazenamento que o banco de dados do WordPress usa. O mecanismo de armazenamento controla como o servidor de banco de dados gerencia os dados que armazena. Você também pode definir um mecanismo de armazenamento diferente por tabela de banco de dados; você não precisa usar o mesmo para todo o banco de dados.

Um servidor de banco de dados possui vários mecanismos de armazenamento. Não vamos olhar para todos eles. Apenas dois nos interessam: InnoDB e MyISAM.

Por padrão, o WordPress usa o mecanismo de banco de dados MySQL padrão. Antes do MySQL 5.5, esse mecanismo era o MyISAM. Se você executa um pequeno site WordPress, o MyISAM está bem. O MyISAM enfrenta problemas de desempenho quando um site cresce em tamanho. Nesse ponto, o InnoDB é a única opção para um mecanismo de banco de dados.

O único problema com o InnoDB é que ele requer alguns ajustes para ter o melhor desempenho. Se você estiver executando um grande servidor de banco de dados, talvez seja necessário ajustar as coisas. Felizmente para nós, existe uma ferramenta para ajudar com isso.

MySQLTuner é um pequeno script que analisa seu servidor de banco de dados. Ele gerará um relatório e fornecerá recomendações de ajuste.

Cache de Objetos

O peso do trabalho de otimizar o ciclo do resultado da consulta está no cache de objetos. O trabalho do cache de objetos é armazenar dados que levam tempo para serem obtidos ou gerados. Como você pode imaginar, as consultas de banco de dados são um candidato perfeito.

O WordPress usa muito o cache de objetos. Digamos que você use get_option para obter uma opção do banco de dados. O WordPress só consultará o banco de dados para essa opção uma vez. Ele não o consultará novamente na próxima vez que alguém precisar dele.

Em vez disso, o WordPress buscará o resultado da consulta do cache do objeto. Este é um passo proativo que o WordPress toma para reduzir o número de consultas ao banco de dados que ele precisa fazer. Mas não é uma solução infalível.

Embora o WordPress faça o possível para alavancar o cache de objetos, um plugin ou tema não precisa. Se um plugin ou tema faz muitas consultas ao banco de dados e não armazena os resultados em cache, a pilha não pode fazer nada a respeito.

Nesses casos, a maioria das consultas ao banco de dados virá do próprio WordPress. Portanto, você obterá uma ótima milhagem com o uso interno do cache de objetos do WordPress. É por isso que é um elemento importante da pilha de servidores WordPress moderna.

Agora, um problema com o cache de objetos é que ele não mantém os dados que armazena por padrão. Ele apenas armazena dados na memória enquanto o PHP está executando todos os arquivos do WordPress. Mas uma vez que o processo PHP termina, todos os dados armazenados na memória são apagados.

Isso não é o ideal. Um cache de objeto pode permanecer válido por muito tempo, portanto, você não deseja limitá-lo a uma única solicitação. A solução é usar um cache de objeto persistente .

Um cache de objeto persistente geralmente vem na forma de um plug-in. Esse plugin faria uso do drop-in object-cache.php para fazer seu trabalho. Este drop-in permite que os autores do plug-in alterem o comportamento padrão do cache do objeto.

Os plug-ins conectam o cache de objetos a um armazenamento de dados persistente. Eles fazem isso substituindo a funcionalidade de busca e salvamento do cache de objetos padrão. Em vez de salvar e buscar dados na memória, o cache de objetos faz isso a partir desse armazenamento.

Plugins de Cache de Objeto Persistente

Atualmente, existem duas opções populares de armazenamento de dados para armazenamento em cache de objetos persistentes:

• Memcached (plug-in)
• Redis (plug-in)

Ambos os armazenamentos de dados usam RAM para armazenamento, o que os torna extremamente rápidos. Na verdade, seu desempenho é comparável ao do cache de objetos padrão.

O único problema é que eles não vêm pré-instalados nos servidores. E nem a extensão PHP (que é opcional com o Redis). Você precisa instalar um antes de poder usar o plugin WordPress correspondente.

Qual você deve instalar? Na prática, não há muita diferença entre os dois para cache de objetos. No passado, a opção popular era o Memcached. Isso mudou nos últimos anos. O Redis adicionou muitos recursos que o tornaram a opção principal para o cache de objetos.

Obtendo seu próprio servidor WordPress moderno

Então, como você consegue seu próprio servidor? A maneira óbvia é obter um de uma empresa de hospedagem WordPress de primeira linha. Essas empresas querem permanecer na vanguarda do negócio de hospedagem WordPress, o que as motiva a adotar os mais recentes avanços e tecnologias.

Mas e se você quiser um sem quebrar o banco? Algumas ferramentas estão disponíveis para quem preferir fazer isso sozinho e pagar menos pela hospedagem. Vamos olhar para eles.

DebOps para WordPress

DebOps for WordPress é uma ferramenta que eu construí para ajudar qualquer pessoa a construir um servidor WordPress moderno. Sua missão é tornar a pilha de servidores WordPress moderna disponível para qualquer pessoa da comunidade. É por isso que estou tentando torná-lo o mais fácil de usar possível. Você não precisa de nenhum conhecimento de administração do sistema para usá-lo.

O DebOps para WordPress configura um servidor com o seguinte:

• HHVM (até que o PHP 7 o torne um repositório oficial do Linux)
• MariaDB
• nginx
• Redis
• Verniz

A ferramenta faz mais do que apenas configurar um servidor com as mais recentes tecnologias. Ele também cuida de proteger o servidor para você. Isso é algo que as pessoas geralmente ignoram ao gerenciar seu próprio servidor.

Easy Engine

EasyEngine é uma ferramenta de linha de comando projetada para ajudá-lo a configurar um site WordPress em um servidor. A grande vantagem do EasyEngine é sua flexibilidade: você pode usá-lo para configurar quase qualquer combinação de tecnologias de servidor que vimos até agora.

Por exemplo, ele permite que você configure um servidor com HHVM ou PHP 7. Ele permite que você escolha entre Memcached e Redis para seu armazenamento de dados persistente. E permite que você instale ferramentas de administrador como o phpMyAdmin.

Ele também oferece um grande número de opções ao criar um site WordPress. Você pode dizer para configurar um site com um cache HTTP usando um plugin ou nginx. Toda essa flexibilidade é o motivo pelo qual o EasyEngine é uma ferramenta tão popular.

Treliça

Trellis é uma ferramenta desenvolvida pela Roots. Assim como o DebOps, ele configura o servidor com um conjunto específico de tecnologias de servidor:

• MariaDB
• Memcached
• nginx
• cache HTTP nginx (opcional)
• PHP7

Uma coisa a saber sobre o Trellis é sua relação com o Bedrock, outra ferramenta construída pela Roots. Bedrock é um clichê para estruturar um site WordPress em torno dos princípios do “Twelve-Factor App”.

A equipe do Roots criou o Trellis para permitir que as pessoas configurem um servidor que usa o(s) site(s) WordPress estruturado(s) da Bedrock. Você não pode usá-lo com uma instalação normal do WordPress, então tenha isso em mente.

Os tempos mudaram

Como você pode ver, um servidor WordPress tem muito mais partes móveis hoje! Mas isso não precisa ser motivo de desespero. Não é tão ruim quanto parece porque você nem sempre precisa usar todas as peças.

É por isso que grande parte deste artigo discute como essas partes funcionam juntas. O objetivo é capacitá-lo a tomar suas próprias decisões. Use esse conhecimento para decidir quais peças você precisa usar e quando. Dessa forma, você também terá um site WordPress rápido.