Exemplo em PHP

O memcached pode ser acessado de muitas linguagens de alto nível, como C/C++, Java, Python, PHP, e até .NET. Abaixo, um exemplo em PHP.
Antes do memcache, uma página poderia ter uma consulta do seguinte tipo:

<?php
// A query SQL está abreviada, apenas como exemplo
// Digamos que essa consulte demore cerca de 1 segundo
// para ser completada
$sql = "SELECT * FROM tabela INNER JOIN ......";
$res = pg_query($sql);
$arr = pg_fetch_all($res); // array com todos os resultados
?>

Com esse código, a cada acesso na página, teremos uma consulta de 1 segundo feita ao banco de dados. Muitas vezes, a consulta será exatamente a mesma. Modificando a consulta para uso do memcached, teríamos algo assim:

<?php
// Conecta ao memcached
$mc = new Memcache;
$mc->addServer('ip.do.servidor');
 
$sql = "SELECT * FROM tabela INNER JOIN ......";
$cache = $mc->get(md5($sql)); // Usamos o md5() da query como chave
 
if ($cache === false) {
    // Resultado não está no cache
    $res = pg_query($sql);
    $arr = pg_fetch_all($res);
    $mc->set(md5($sql), $arr);
}
else {
    $arr = $cache;
}
?>

Pelo exemplo acima, temos algumas modificações. Primeiramente conectamos ao memcached. A chamada a addServer() pode ser feita múltiplas vezes, caso existam vários memcached rodando em máquinas separadas. Pode ser dado um “peso” pra cada servidor também, de acordo com a memória disponível em cada um.
Logo em seguida, é feita a verificação no memcached se o resultado da consulta já está lá. Como chave, usei o hash md5 da consulta, pra gerar uma identificação única. O método get() pode retornar false, caso a chave não esteja no memcached, ou retornar o objeto que foi guardado.
A checagem é simples. Se o get() retornou false, então o sistema faz a consulta como já fazia antes, e no fim guarda o resultado no memcached, pra agilizar as próximas consultas. E caso não tenha retornado false, temos já o resultado da consulta diretamente. Ao fim do bloco if, teremos, de uma forma ou de outra, o resultado da consulta em $arr.
A diferença é que rodando a consulta no banco, o tempo será de cerca de 1 segundo (tempo que estimamos para a execução da consulta), e pegando o resultado direto do memcached, a consulta demorará algo da ordem de milissegundos para ser completada.

Problemas

Um dos problemas clássicos em qualquer abordagem que use cache é como saber se as informações em cache ainda estão atuais. Com o memcached, isso não é diferente. Existem algumas formas de se lidar com o problema.
A primeira delas, mais simples, e que pode ser usada livremente caso não seja de suma importância que os dados estejam atuais, é mexer no tempo em que a informação ficará no cache. O tempo pode ser especificado na chamada ao método set(), da seguinte forma:

<?php
$mc->set(md5($sql), $arr, MEMCACHE_COMPRESSED, 60);
?>

Temos neste exemplo todos os parâmetros para a chamada de set(): a chave, o objeto a ser guardado, uma flag (pode ser usado MEMCACHE_COMPRESSED, que indica que o objeto será comprimido para ocupar menos espaço, ou 0 pra indicar que deve ser guardado sem compressão), e por último o tempo de vida do objeto, no caso, 60 segundos.
Ou seja, caso não haja problema das informações permanecerem desatualizadas por 60 segundos no máximo, essa abordagem pode ser usada.
Caso a informação tenha que estar sempre atualizada, a forma de tratamento terá que ser outra. O memcached possui método para apagar o objeto associado a uma chave. Tendo a chave, basta usar:

<?php
$mc->delete('chave');
?>

e a entrada que existia no memcached para aquela chave será invalidada.
A idéia, nesse segundo caso, é justamente localizar no código todos os pontos que modificam o banco de dados de forma que possa alterar o resultado da consulta feita, e adicionar código para invalidar o cache nesses pontos. Assim, quando for feita a consulta no memcached, caso alguma informação tenha sido modificada, a entrada correspondente no memcached já terá sido apagada, e a chamada a get() retornará false naturalmente.
É claro que essa segunda abordagem dá muito mais trabalho, por isso a sugestão de se usar a primeira delas nos casos em que pode ser usada. Lembre-se que em um site com 100 acessos por segundo, um tempo de vida de 60 segundos evitará 5999 consultas ao banco (a primeira será feita e guardada).

Mais informações

O site do projeto tem um Wiki que responde a maior parte das dúvidas que se pode ter, em relação a instalação e ao uso.
No caso do PHP, as funções são bem documentadas na parte do manual sobre memcache.
Eu uso em produção o memcached, com 2 servidores, um com 768mb de memória disponíveis para o memcached e outro com 256mb. Dei pesos 3 e 1 respectivamente, para que um objeto tenha 3 vezes mais chance de cair no primeiro servidor. A configuração está bastante satisfatória, e o banco de dados agradece.

Artigos relacionados

• Evitando SQL injection em PHP
• Otimização: imagens inline
• Otimização de sites, parte 3 – Cache
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify
• Problemas com acentuação?
• O limite de 4 (ou 3?) Gb de memória

O problema

A razão desse “problema” é simples: o sistema operacional é de 32 bits. Se o sistema operacional é de 32 bits, significa que o maior número que ele pode colocar alocar em um registrador (pequena unidade de memória que fica dentro do processador) é um número de 32 bits. Como endereços de memórias são números, o espaço máximo possível de endereçamento tambem tem 32 bits. E fazendo a conta, temos que 2^32 = 4 Gb.

No Windows, o espaço fica limitado em 3 Gb, porque 1 Gb é reservado para o kernel do sistema.
Pronto, já entendemos o porque do problema. Agora, o que fazer para solucioná-lo?

A solução limpa

A primeira solução, e a melhor delas, é migrar para um sistema operacional de 64 bits. Além do ganho no espaço de endereçamento, programas em 64 bits fazem uso melhor do processador.

Considero esta solução como limpa por ser algo nativo. Os programas são compilados em modo 64 bits, e naturalmente já possuem este espaço de endereçamento.

Existem versões 64 bits dos sistemas operacionais mais populares: Linux, Windows (XP/Vista).

Porém, existem casos em que a migração não pode ser feita, e aí existe uma “gambiarra” que pode ser feita pra se aumentar um pouco o espaço de endereçamento.

A solução porca

Praticamente todos os processadores de hoje em dia (Intel do Pentium Pro em diante, e AMD do Athlon em diante) suportam PAE, ou Physical Address Extension (Extensão de endereçamento físico). A idéia é adicionar mais 4 bits no espaço de endereçamento, aumentando para 36 bits, que nos dá: 2^36 = 64 Gb de espaço.

Claro, o PAE depende tambem do sistema operacional. Chamo de gambiarra, porque os programas continuam enxergando no máximo 32 bits (ou seja, os programs continuam limitados a 4 Gb de memória), e quem gerencia o espaço total é o sistema operacional. Cabe a ele decidir quais programas acessam quais espaços de 32 bits. Não é algo nativo.

Além disso, o sistema vai ficar todo um pouco mais lento, devido ao processamento extra que precisa ser feito pelo sistema operacional para gerenciar esses 4 bits extras.

Windows

No mundo Windows, o espaço total suportado pelo sistema operacional depende da versão. O XP enxerga no máximo 4 Gb de memória, mesmo com PAE. Outras versões variam um pouco.

Para se utilizar a memória extra provida pelo PAE, é preciso abrir o arquivo boot.ini, e adicionar o parâmetro /PAE na linha correspondente.

O lado ruim de usar no Windows é que o espaço total não depende somente do PAE, e sim da versão do Windows utilizada. Ou seja, além da restrição dos 64 Gb, o sistema operacional também impõe restrições extras, de modo que dependendo da versão, o sistema continuará sem conseguir enxergar a memória inteira (vide Windows XP e o limite de 4 Gb).

Linux

No Linux, as coisas são um pouco mais tranquilas. Basta habilitar o suporte a PAE no kernel do sistema, e ter todos os módulos também compilados com suporte a PAE. A opção relevante fica na parte “Processor type and features”, em “High Memory Support”.

Ali se escolhe entre desligado, onde o sistema enxerga no máximo 1 Gb de memória, e é a opção recomendada para computadores com 1 Gb ou menos de memória, por ser mais rápida, 4 Gb ou 64 Gb. A opção desejada é a 64 Gb, para utilizar todos os 36 bits disponibilizados, sem nenhuma restrição adicional, como acontece no Windows.

Na prática

Em casa, estou utilizando tanto o Windows XP x64 Edition quanto o Linux (Ubuntu 8.10 – 64 bits) sem maiores problemas. No Windows, consegui driver pra tudo nos sites dos fabricantes (Abit – placa mãe, nVidia – placa de vídeo). No Linux, o Ubuntu cuidou de tudo pra mim, embora possam existir problemas com o driver binário da nVidia (tentei fazer o upgrade para o 9 e não consegui).

No Linux, os únicos programas que tive problema foram os emuladores, que por precisarem de muita velocidade, tem partes que são feitas diretamente em Assembly (pra 32 bits), e por isso nem sempre compilam diretamente em 64 bits. Porém, existe sempre a possibilidade de se executar programas 32 bits, bastando ter as bibliotecas 32 bits que o programa necessita.

No Windows, até agora, não tive problema nenhum.

Artigos relacionados

• Personalizando CFLAGS por pacote no Gentoo
• Otimização de sites com memcached