Configurar o WordPress Multisite, também conhecido como WordPress MU ou simplesmente WordPress Multiblog, pode em alguns casos ser uma dor de cabeça devido principalmente às configurações dos servidores web que servem os pedidos ao WordPress. Nesta primeira parte da série iremos abordar como facilmente ligar e instalar a opção Multisite do WordPress tentando abordar todo o tipo de configurações que o seu servidor possa deter incluindo diferentes ambientes e servidores. Nesta parte não vamos ainda olhar as soluções para montar ou escalar uma rede com muitos blogs – estamos ainda a dar os passos iniciais!

Durante esta série de tutoriais iremos:

  • Ensinar como ligar facilmente a opção de Multisite no WordPress e o que fazer após a instalação do Multisite concluída;
  • Abordar soluções de plugins testados que podem ajudá-lo no desenvolvimento do seu projecto para criar facilmente a sua rede de blogues;
  • Desenvolver snippets de códigos e mostrar o “canivete suíço” de funções exclusivas do WordPress Multisite;
  • Abordar várias soluções de configuração e ambientes de trabalho: desde o servidor web Apache ao servidor Nginx, passando por outras soluções de routeamento estático tais como o servidor lighttpd;
  • Abordar as soluções de cache em memória, usando memcached ou APC, assim como soluções de cache persistente estáticas em disco, para acelerar a sua rede e evitar ligações perdidas;
  • Aumentar o poder da sua instalação WordPress Multisite de modo a poder aceitar mais ligações simultâneas sem perda de performance dos seus sites;
  • Escalar a sua rede para usar multiplas bases de dados e aumentar o poder da sua rede;
  • Como estruturar e manter uma rede com mais de 1 milhão de blogues;
  • Mostrar soluções encontradas para problemas com o Multisite;
  • Desenvolver teoricamente configurações de rede Multisite para várias soluções de mercado;

PARTE III – ESTRUTURA DO BANCO DE DADOS E ESCALONAMENTO DO MYSQL

Na primeira parte desta série abordámos questões relacionadas com a instalação do WordPress multisite em vários ambientes e configurações. Na segunda parte falámos sobre como aumentar a performance do servidor. Nesta parte mais técnica, iremos falar da estrutura da base de dados de uma instalação multisite, como funciona se você quiser escalonar a rede e algumas soluções para poder usar vários bancos de dados na mesma instalação do WordPress.

ESTRUTURA DA BASE DE DADOS

Como é sabido, uma instalação do WordPress em Multisite permite ter vários blogues ou sites em simultâneo a correr na mesma instalação de modo simultâneo, permitindo centralizar vários sites com alguma independência na mesma rede, partilhando usuários, plugins e temas.

O WordPress.com é um exemplo de uma instalação de WordPress Multisite. Este serviço que permite qualquer um ter um blogue totalmente gratuito em minutos, é uma rede enorme que alberga milhões de blogues em servidores localizados em todo o mundo. Isto tudo numa única instalação WordPress Multisite que é partilhada por todos estes servidores.

Mas como é que eles fazem isso? Escalar uma rede multisite pode ser complicado, no entanto para se saber melhor como isto funciona iremos primeiro entrar na estrutura da base de dados de uma rede multisite.

Num banco de dados de uma instalação normal de um WordPress encontramos as seguintes tabelas:

  • wp_posts e wp_postmeta: guardam os posts criados pelos usuários.
  • wp_links: guardam os links do painel de Links.
  • wp_comments e wp_commentmeta: contém todos os comentários criados pelos visitantes do seu site.
  • wp_users e wp_usermeta: aqui ficam informações sobre os usuários registados.
  • wp_options: esta tabela contém todas as informações de configuração do WordPress.
  • wp_terms, wp_term_relationships e wp_term_taxonomy: todas as taxonomias e termos (incluindo as Categorias e Tags) estão contidas aqui.

Não nos vamos alongar com mais informações acerca do banco de dados, ficando aqui a informação substancial. Em relação a uma rede de sites, quando ativamos a funcionalidade do multisite no WordPress, são criadas no banco de dados novas tabelas que irão albergar mais informação que é importante ter numa rede de sites como por exemplo, que sites existem na rede, domínios, subdomínios e que usuários têm acesso aos sites entre outras informações importantes. São estas as tabelas criadas nesse processo:

  • wp_site e wp_sitemeta: contém todas as informações sobre a rede de sites. Por defeito apenas uma rede multisite está definida. Trataremos disto no próximo artigo.
  • wp_blogs e wp_blog_versions: contém todos os sites definidos na rede, o seu domínio por defeito e o historial de todas as atualizações feitas na rede.
  • wp_signups e wp_registration_log: todos os registos de novos usuários e novos sites ficam registados nestas tabelas.

E são apenas estas as alterações. Agora, se você criar um novo blog dentro do painel de administração da rede e voltar ao banco de dados você verá que novas tabelas foram criadas especificamente para o blog que você acabou de criar. Essas tabelas não são nada mais nada menos que uma “cópia limpa” das tabelas que vêm incluidas numa instalação de WordPress normal à excepção das tabelas wp_users e wp_usermeta, pois estas são globalmente partilhadas na rede. As tabelas que foram recentemente criadas têm um prefixo wp_2_* ou seja, 2 é o ID do blog que você acabou de criar.

É por isso que o WordPress Multisite consegue fazer a gestão de vários milhares de blogues numa única rede: as tabelas para cada um dos blogs são independentes, garantindo que não exista demasiadas entradas numa mesma tabela, pois isso iria abrandar significativamente qualquer consulta ao banco de dados.

ESCALONAR O BANCO DE DADOS DO WORDPRESS MULTISITE MANTENDO A PERFORMANCE

Quando um blog de uma rede multisite é acessado por um visitante, o PHP inicia o WordPress, tendo este o trabalho de “puxar” a informação pretendida do banco de dados. A maior parte do trabalho na verdade é feito pelo MySQL. É sabido que quanto mais conteúdo for colocado num banco de dados MySQL mais lenta se torna qualquer consulta a ele. Também é sabido que o MySQL é um servidor que consome muitos recursos…

À medida que a sua rede multisite se vai alargando para as centenas ou mesmo milhares de blogues, você vai começando a reparar que os seus sites vão ficando mais lentos. Assim, para manter a performance da rede, você vai precisar de fazer algumas alterações. O MySQL é um serviço “pesado”, que consume muito processador e memória RAM quando se gera um pedido. Desta maneira, uma das alterações mais eficazes é separar fisicamente a “Web” do “Banco de dados”, isto é, arrumar um servidor para correr o seu serviço web Apache e outro apenas para manter o seu banco de dados MySQL.

É aconselhável que os servidores tenham as mesmas especificações, ou seja, a mesma memória RAM e velocidade de acesso à memória, velocidade em disco duro e que o processador onde o servidor do MySQL reside seja um pouco “mais rápido” que o processador do lado web, no mínimo que tenham o mesmo número de cores. Isto porque, como escrito já em cima, o MySQL é um devorador de recursos e, se você não quiser atrasar sua conexão convém fazer com que o MySQL “despache” rapidamente qualquer pedido. Obviamente, algo muito importante nesta estrutura e que está faltando neste desenho é a ligação entre as duas máquinas: quanto mais perto uma da outra estiverem melhor, ou seja, residam no mesmo datacenter, e melhor ainda ficará se a ligação entre as duas for na ordem do gigabit. .

Tenha em atenção que qualquer pedido feito à máquina web vai demorar ser processado e assim, aquilo que você mais deseja é que o pedido seja entregue o mais rapidamente possivel com poucos recursos. Assim, antes de avançar com a implementação faça um teste de ping entre as duas máquinas. Na consola digite:

ping IP_do_servidor_remoto

Você deverá no máximo obter um valor médio de tempo de espera à volta dos 8 milisegundos. Qualquer valor acima disto acaba atrasando essa conexão.

Depois disto tudo feito você irá realmente encontrar melhorias na sua rede. Os seus blogues começam a funcionar mais rapidamente e, combinando esta configuração com o que foi apresentado na parte dois desta série, a sua rede irá conseguir responder a mais conexões em simultâneo sem falhas e com a mesma rapidez de sempre.

Plugin Hyper DB, da Automattic:

A Automattic, a empresa por trás do WordPress.com, desenvolveu um plugin baseado no trabalho já feito por eles que permite a qualquer rede multisite conectar-se a mais do que um banco de dados em simultâneo.

Como falado em cima, um banco de dados MySQL vai gradualmente ficando mais lento com o aumento de entradas nas suas tabelas. Neste caso a única maneira de manter a performance é dividindo o banco de dados em vários bancos de dados espalhados por vários servidores correndo MySQL. Como o WordPress nativamente apenas se conecta a um único banco de dados, este plugin poderá ser uma resposta para esses casos mais extremos em que a quantidade de informação é enorme.

Fazer o Download o plugin Hyper DB da Automattic

Configurando o Plugin:

  1. Descarregue o ficheiro e ZIP e descompacte para o um diretorio local
  2. Copie o ficheiro db-config.php para o servidor web, no mesmo diretorio que o wp-config.php da sua instalação
  3. Abra ambos os ficheiros db-config.php e wp-config.php
  4. No ficheiro wp-config.php, coloque o seguinte código
    define('DB_CONFIG_FILE', true);
  5. Salve o ficheiro wp-config.php
  6. No ficheiro db-config.phpprocure pela linha que contém
    $wpdb->max_connections = 10;

    e aumente o valor para mais conexões caso você esteja esperando mais visitantes aos seus blogs. Nota: tenha cuidado em testar esta configuração antes de a colocar em produção pois a performance pode variar de servidor para servidor.

  7. No mesmo ficheiro vamos definir quais os bancos de dados que existem e com os quais queremos trabalhar. Remova qualquer definição de banco de dados já criado e acrescente a seguinte informação:
    $wpdb->add_database(array(
    	'host'     => DB_HOST,     // Se a porta não for 3306, use host:port.
    	'user'     => DB_USER,
    	'password' => DB_PASSWORD,
    	'name'     => DB_NAME,
    	'write'	   => 1,
    	'read'     => 0,
    	'dataset'  => 'global',
    	'timeout'  => 0.2,
    ));
    
    $wpdb->add_database(array(
    	'host'     => DB_HOST,     // Se a porta não for 3306, use host:port.
    	'user'     => DB_USER,
    	'password' => DB_PASSWORD,
    	'name'     => DB_NAME,
    	'write'    => 0,
    	'read'     => 1,
    	'dataset'  => 'global',
    	'timeout'  => 0.2,
    ));

O método $wpdb->add_databse() é responsável por adicionar novos bancos de dados ao WordPress. No código acima definimos o banco de dados usual configurado no wp-config.php duas vezes. Porquê? No primeiro trecho ele está configurado para servir como master e no segundo como slave através das propriedades write e read.

Um banco de dados configurado com write = 1 irá ser o master e receberá todas as modificações realizadas nas tabelas. Um banco de dados configurado como read = 1 irá servir como slave e receberá apenas leituras. Desta forma podemos balancear o carregamento dos nossos blogs.

Se você quiser acrescentar mais bancos de dados só de leitura, você só terá que adicionar mais uma instância $wpdb->add_database() com o read = 1.

Ordem de leitura 

Em cada uma instância do banco de dados, você poderá mudar a ordem com que você quer que seus servidores MySQL sejam acedidos. Imagine que você tem uma rede de blogues muito complexa, com duas estruturas de rede diferentes em vários locais do mundo. Numa situação mais simples você tem o que vê na imagem seguinte:

A sua rede está espalhada por dois datacenters localizados em sitios diferentes do globo. Cada servidor web está ligado a 3 servidores MySQL. Você poderá privilegiar uns bancos de dados sobre os outros. Isso é feito através da ordem dada na propriedade read.

Exemplo de configuração no Datacenter de Lisboa

MySQL Local Escravo: read = 1
MySQL Local Escravo 2: read =
MySQL Local Master: read = 3

MySQL São Paulo Escravo: read = 4
MySQL São Paulo Escravo 2: read =
MySQL São Paulo Master: read = 6

Desta forma você garante que o o WordPress irá tentar conectar-se primeiro aos servidores MySQL locais e só depois, caso estes estejam demasiado ocupados para responder a novos pedidos, tentar conectar-se com os servidores de São Paulo.

Tenha em atenção que esta é uma configuração simples. Você deverá depois usar o sistema de replicação nativa do MySQL para poder replicar as alterações do master para os slaves.

Esperamos que este artigo o tenha ajudado a implementar e a aumentar a performance da sua rede de blogs e que seja benéfico para o aprendizado de como escalonar bem uma rede de sites em WordPress.

Até breve!