SPIP

[ar] [ast] [bg] [br] [ca] [co] [cpf] [cs] [da] [de] [en] [eo] [es] [eu] [fa] [fon] [fr] [gl] [id] [it] [ja] [lb] [nl] [oc] [pl] [pt] [ro] [ru] [sk] [sv] [tr] [vi] [zh] Espace de traduction

Télécharger

Gerir a cache

e evitar sobrecarregar o servidor que tem mais que fazer

Agosto de 2005

Todas as versões deste artigo :


Nas lições anteriores começámos a criar esqueletos. O sucesso do nosso sítio arrisca-se a ser fulgurante. Precisamos de pensar imediatamente nos pobres neurónios do nosso computador. Nesta lição não há nada de divertido nem de essencial. Os menos dados ao trabalho podem aproveitar para dormitar enroscados perto do aquecedor...

Resumo para estes e para os apressados: nos ficheiros de chamada do tipo tutorial.php3, defina $delais = 3600; em vez de 0.

...

No momento em que uma página é pedida ao SPIP, este verifica se, por acaso, não calculou já esta página. Se o URL pedido é http://seusitio.net/tutorial.php3?id_article=12, o SPIP verifica, no seu subdirectório CACHE/ se este ficheiro existe e, nesse caso, compara a idade do ficheiro em cache com os $delais [1] fixados no ficheiro de chamada tutoriel.php3.

No nosso exemplo tínhamos fixado o prazo $delais=0; - que levava a um novo cálculo sistemático das páginas a cada consulta ao sítio. Passemos a $delais=3600; (leva apenas alguns segundos).

A nossa página de Internet só é recalculada se, quando um visitante a invoca, a sua versão em cache tem mais de uma hora (ou seja, 3600 segundos.). Caso contrário, o SPIP lê simplesmente o conteúdo do ficheiro em cache [2], e reenvia os resultados sem se ligar à base de dados (excepto para aí inserir um «hit» nas estatísticas).

Como fixar estes $delais de modo a optimizar a relação reactividade/carga do servidor? Não existe solução milagrosa, mas não hesite em fixar um prazo de um dia (isto é, $delais=24*3600;) ou mais para os artigos e as rubricas. As páginas de navegação mais importantes podem ter $delais mais curtos (vinte minutos ou uma hora, por exemplo) se o seu sítio tem de reagir à validação frequente de novas breves e de sítios sindicados... Se você partilha um servidor com outros sítios, respeite os outros e não monopolize o tempo de cálculo para páginas que raramente mudam: seria tão mais idiota quanto, em artigos «pesados» ou nos sumários, o cálculo das páginas pode levar alguns segundos, o que torna mais lenta a consulta das suas páginas...

Como provocar uma actualização fora dos prazos? Acabamos de decidir $delais extremamente longos, e apercebemo-nos de um ero otografico numa página. Correcção no espaço privado... Como apagar imediatamente esta mancha vergonhosa do sítio?

-  No espaço privado, clicar em «Ver em linha» desencadeia o recálculo para as páginas correspondentes a #URL_ARTICLE ou #URL_RUBRIQUE do artigo ou da rubrica correspondente. É o caso mais comum. E se não for esse o caso?

-  Na parte «Salvaguarda/Restauro» do espaço privado, um botão «esvaziar a cache» apaga todos os ficheiros em cache (útil se você faz muitas alterações e tem um sítio muito complexo, a evitar se não for o caso).

-  No entanto, a solução mais simples é pedir ao SPIP, na página de entrada do espaço privado, que lhe «envie um cookie de administração». Este cookie ficará alojado no seu navegador, e o SPIP vai reconhecê-lo no momento de lhe enviar a página do sítio público: propor-lhe-á então, no topo ou no fundo da página, um botão «Recompor esta página».

-  Voltando ao contexto: Voltamos aqui à noção de contexto. Se o esqueleto é invocado com um contexto de id_article, de id_rubrique ou ainda de id_breve, é-lhe proposto um outro botão quando o SPIP detecta o cookie: «Modificar este artigo (ou rubrica, ou breve)», que o leva directamente à página correspondente no back-office. Obrigado a quem?

Últimos detalhes:
-  por razões evidentes, o motor de busca não desencadeia a cache, e as páginas com fórum são reactualizadas de cada vez que é enviada uma nova contribuição.
-  o directório CACHE/ na estrutura em árvore do sítio está subdividido em 16 subdirectórios numerados 0, 1, 2... 9, A, B... F, pelos quais os ficheiros em cache são distribuídos quase aleatoriamente; isso tem o nome «hasher a cache [3]» e só por isso bem merece que o mencionemos.
-  os ficheiros guardados na cache são explorados mesmo se a base de dados «estiver em baixo», o que garante o sítio contra quebras transitórias do servidor MySQL..

Notas

[1délai significa, em francês, "prazo"

[2Para os especialistas, trata-se na verdade de um include PHP do ficheiro correspondente, que permite executar código a partir da cache...

[3do verbo inglês «to hash», que como termo culinário significa «picar»


Importar o esqueleto desta página Sítio realizado com SPIP | Espace de traduction | Espaço privado