Nem todo código WP é código público
Se você vai divulgar algo público, todas as coisas que kovshenin disse são perfeitamente válidas.
As coisas são diferentes se você escrever um código privado para você ou sua empresa.
O cache de objetos externos é um grande benefício, em qualquer caso
É muito recomendável definir um cache de objeto persistente externo , quando possível.
Todas as coisas ditas na resposta do kovshenin sobre transientes e MySQL são muito verdadeiras, e considerando que o próprio WP e vários plugins fazem uso do cache de objetos ... então a melhoria de desempenho obtida, vale absolutamente o (pequeno) esforço de configuração um sistema de cache moderno como Redis ou Memcached.
Valores em cache podem não estar lá: tudo bem
Além disso, sim, um cache de objeto externo não é confiável. Você nunca deve confiar no fato de que existe um transitório. Você precisa garantir que funcione se o cache não estiver onde deveria estar.
Cache não é armazenamento, cache é cache.
Usar cache seletivamente
Veja este exemplo:
function my_get_some_value($key) {
// by default no cache when debug and if no external object_cache
$defUse = ! (defined('WP_DEBUG') && WP_DEBUG) && wp_using_ext_object_cache();
// make the usage of cache filterable
$useCache = apply_filters('my_use_cache', $defUse);
// return cached value if any
if ($useCache && ($cached = get_transient($key))) {
return $cached;
}
// no cached value, make sure your code works with no cache
$value = my_get_some_value_in_some_expensive_way();
// set cache, if allowed
$useCache and set_transient($key, $value, HOUR_IN_SECONDS);
return $value;
}
Usando um código como esse, em seu site privado, o desempenho do site pode melhorar muito , principalmente se você tiver muitos usuários.
Observe que:
- Por padrão, o cache não é usado quando a depuração está ativada, assim esperançosamente em seu ambiente de desenvolvimento. Acredite, o cache pode tornar a depuração um inferno
- Por padrão, o cache também não é usado quando o WP não está configurado para usar um cache de objeto externo. Isso significa que todo o problema conectado ao MySQL não existe, porque você não usa transitórios quando eles usam o MySQL. Uma alternativa provavelmente mais fácil seria usar
wp_cache_*funções ; portanto, se nenhum cache externo estiver configurado, o cache ocorrerá na memória e o banco de dados nunca estará envolvido.
- O uso do cache é filtrável, para lidar com alguns casos extremos que você pode encontrar
Sem escala da Web se não houver cache
Você não deve tentar resolver problemas de velocidade com o cache. Se você tiver problemas de velocidade, deve repensar o código.
Mas, para dimensionar um site em escala da web, o cache é bastante necessário .
E muitas vezes (mas nem sempre) fragmentam, o cache sensível ao contexto é muito mais flexível e adequado do que o cache agressivo de página inteira.
Suas perguntas:
Devo usar a API transitória aqui?
Depende .
Seu código está consumindo muitos recursos? Caso contrário, talvez não haja necessidade de cache. Como dito, não é apenas uma questão de velocidade. Se o seu código é rápido, mas requer muita CPU e memória para alguns usuários ... o que acontece quando você tem 100 ou 1000 usuários simultâneos?
Se você perceber que o cache seria uma boa ideia ..
... e é um código público: provavelmente não . Você pode considerar o cache seletivamente, como no meu exemplo acima, em código público, mas geralmente é melhor se você deixar essas decisões para os implementadores.
... e é um código privado: muito provavelmente sim . Mas mesmo para o código privado, armazenar em cache seletivamente ainda é uma coisa boa, por exemplo, para depuração.
Lembre-se, de qualquer maneira, que wp_cache_*funções podem fornecer acesso ao cache sem o risco de poluir o banco de dados.
Devo usar a API transitória para armazenar em cache a matriz $ related_posts ou a cadeia $ html_output?
Depende de muitas coisas. Qual é o tamanho da corda? Qual cache externo você está usando? Se você estiver indo para cache de postagens, armazenar uma ID como matriz pode ser uma boa idéia, consultar um número decente de postagens por sua ID é bastante rápido.
Notas Finais
API transitória é provavelmente uma das melhores coisas do WordPress. Graças aos plugins que você pode encontrar para qualquer tipo de sistema de cache, torna-se uma API simples e estúpida para um grande número de software que pode funcionar sob o capô.
Fora do WordPress, é muito difícil encontrar essa abstração que funciona imediatamente com um monte de sistemas de cache diferentes e permite que você alterne de um sistema para outro sem nenhum esforço.
Você raramente pode me ouvir dizendo que o WordPress é melhor do que outras coisas modernas, mas a API transitória é uma das poucas coisas que sinto falta quando não trabalho com o WordPress.
Certamente o cache é difícil, não resolve problemas de código e não é uma bala de prata, mas é algo que você precisa para criar um site de alto tráfego que funcione.
A idéia do WordPress de usar uma tabela MySQL sub-otimizada para fazer cache é bastante insana, mas não é melhor manter-se longe do cache apenas porque o WordPress, por padrão, faz isso.
Você só precisa entender como as coisas funcionam e depois fazer sua escolha.