Este artigo é, antes, de uma série de "notas de anfitriã". Bem, um pouco mais sobre experiências pessoais e goivagem.
Se você precisar lidar com sites WordPress com o plug-in de cache WP Super Cache instalado, o artigo poderá ser útil para você. Caso contrário, isso é apenas uma pequena história.
Em suma, o começo da história é este: havia um site. Notícias e informações temáticas. Feito por um assistente desconhecido no CMS WordPress. E feito exatamente como foi permitido naquele momento pelos meios de seu dono. Com o tempo, o site ganhou popularidade, o número de visitantes cresceu. O site em si "ganhou" em publicidade. I.e. quanto mais visitantes, melhor. Em algum momento, durante os picos de carga, o site começou a aparecer: páginas carregadas lentamente e tudo mais. Mas, é claro, até o pau bicar, ninguém realmente se mexeu. O galo apareceu no momento em que o site deveria cobrir algum evento que atraiu a atenção do público. Os visitantes chegaram, o site caiu e toda a receita estimada estava derretendo diante de nossos olhos. Devido às circunstâncias, tive que atuar como um ressuscitador. Eu escrevi
um artigo sobre isso então. Minha decisão foi assustadora (não repita), mas o objetivo principal foi cumprido - os sonhos foram salvos. Principalmente.
Obviamente, ninguém estava interessado em repetir uma situação semelhante e trabalhou no site. Primeiro, eles descobriram os motivos da queda e da alta carga no servidor. Eles eram comuns: a falta de um site de cache em si e um mecanismo mal implementado para registrar e exibir o número de visualizações de artigos. Este último criou uma carga decente: com cada solicitação para a página do artigo, ele pegava no banco de dados o número de visualizações deste artigo, exibia-o e, em seguida, adicionava um e o escrevia de volta ao banco de dados. Ao mesmo tempo, a tabela
wp_postmeta com metadados foi usada para armazenamento (como parece ser chamado no WP). Em que a massa foi armazenada completamente irrelevante para as visões contábeis das informações e que era muito grande.
O problema de armazenamento em cache foi resolvido simplesmente: em um ambiente silencioso, o plug-in WP Super Cache era instalado normalmente. O que muitos, se bem me lembro, me aconselharam a fazer, em vez da muleta sinistra que construí nos comentários desse artigo meu. Honestamente, eu então e agora navegava mal no ecossistema do WordPress e, portanto, essa muleta apareceu. O plug-in de armazenamento em cache foi instalado e configurado por pessoas que já conheciam e saiu da caixa. Assim, o problema de armazenamento em cache foi resolvido. Por que esse plugin foi escolhido, não sei ao certo. Tanto quanto eu entendo, este é um dos plugins mais populares desse tipo para o WP.
Dadas as opiniões, eles agiram de maneira um pouco diferente. É claro que o mecanismo original teve que ser abandonado. Não queria me recusar a levar em conta as opiniões: pelo menos um bloco exibido como "os artigos mais populares da semana" estava vinculado a ele. Todos os plug-ins para gravar visualizações, mesmo que fossem "amigos" do plug-in de cache, mostraram-se muito vorazes e, na maioria das vezes, implementaram o mesmo mecanismo com a gravação e extração de dados do wp_postmeta. Para um site pequeno, isso é bastante adequado. Para um site com taxas de frequência de pico bastante sólidas - não é mais: glutão demais para uma função tão pequena. Então, a propósito, eu apareci hospedagem paga e não utilizada nos próximos anos. O mais fácil e mais barato. As responsabilidades de armazenar, registrar e devolver dados sobre visualizações estavam nele. Tudo é assíncrono, ou seja, mesmo que caia, o site principal continuará exibindo silenciosamente artigos, anúncios e tudo o que deve exibir. O armazenamento online dos dados de visualização foi atribuído ao Redis e o armazenamento de longo prazo ao MySQL. Por isso, está girando, não é realmente necessário e consome 1-2% da carga máxima permitida nessa hospedagem.
E assim, passa muito tempo. Novamente noite e novamente uma história antiga. Um tráfego bastante poderoso vai para o site e o site começa a cair. E, novamente, sou o único especialista condicional acordado na área. É claro que estou surpreso com a repetição de eventos. Meu primeiro pensamento é que alguém acidentalmente desativou o cache. Mas não, no código fonte da página do site que o servidor em queda me fornece, vejo sinais de um plug-in de cache funcionando. Tudo deve ficar bem. Mas no painel de controle do servidor, vejo que não há RAM, o número de consultas ao banco de dados é incrível e tudo está ruim. Antes de tudo, abro a página com a descrição do plugin, corro rapidamente pelos olhos dela, não encontro nada e deixo essa atividade. O próximo passo é ver as estatísticas. Vejo que o fluxo de tráfego principal está fluindo para o site a partir do Yandex.Zen. E a solicitação que leva o usuário ao site é assim:
https://example.com ? utm_referrer = https:% 2F% 2Fzen.yandex.com
I.e. Yandex.Zen adiciona sua tag utm ao endereço. Como o servidor já está completamente deitado e me dá apenas 500, por algum motivo, não posso verificar claramente a teoria de que páginas com essa "ponderação" não são armazenadas em cache. Portanto, outra "muleta" nasce (foi substituída posteriormente): um redirecionamento é adicionado ao .htaccess, que converte a solicitação com tags utm em uma solicitação sem elas antes que o WordPress e todos os seus plugins poderosos entrem em jogo. A máquina é reinicializada e, pronto, tudo funciona: o site carrega rapidamente, o servidor silenciosamente se move em baixas velocidades. Como nada aconteceu.
Então relaxei e subi calmamente assistindo as configurações do plug-in de cache. Primeiro de tudo, a caixa de seleção "Não armazenar em cache páginas com parâmetros GET", que está lá. Está tudo bem, ela não vale a pena. Além disso, como o experimento mostrou, o plug-in lida com o cache de consultas com qualquer conjunto de parâmetros arbitrários. Se essas não são tags utm (na verdade, apenas redirecionei solicitações de um determinado tipo e não cortei todas as tags utm).
Aqui eu cuidadosamente (usando CTRL + F) olhei para a página do plugin. E encontrei no FAQ o glorioso parágrafo "Como devo usar melhor as ferramentas de rastreamento utm_source no Google Analytics com este plug-in?". É claro que, durante o primeiro exame superficial, eu o ignorei com segurança: parece não haver nada a ver com o problema. Ao mesmo tempo, a propósito, não é muito informativo e não oferece nenhuma solução específica.
A única conclusão útil possível no artigo: se você possui um site WP com o plug-in WP Super Cache, verifique o que ele faz (ou não), se você enviar uma solicitação com os parâmetros “? Utm_referrer = https:% 2F% 2Fzen. yandex.com "etc. Não tenho certeza de que, ao instalar este plug-in, todos leiam suas perguntas frequentes com muito cuidado. A implementação específica, aparentemente, permanece com os proprietários do site: quando olhei pela última vez para a atualização deste plug-in, não vi alterações relacionadas à sua estranha reação às tags utm.
Mas a história teria sido incompleta (e eu não teria contado) se não houvesse outra confirmação da lei de Murphy. Enquanto nos correspondíamos pacificamente com o proprietário do site e observamos como o site funcionava silenciosamente por cerca de uma hora ... o site caiu. Inesperadamente e finalmente. Não há acesso ao painel de controle do servidor, FTP, SSH e tudo o mais não funciona. Nada funciona Se antes disso minha pressão foi levemente aumentada ao resolver o problema que J. Zen e o plug-in de armazenamento em cache criaram (afinal, é um prazer especial entender e corrigir rapidamente algo de uma maneira fácil), então um ataque de mini-pânico inteiro aconteceu comigo. E apenas a vaga sensação de que algumas linhas no .htaccess não podem matar tudo uma hora depois de criar essas linhas não permitiu que o “mini” se transformasse em algo mais completo. Em geral, após alguns minutos de troca de mensagens surpresas, entramos na conta pessoal do provedor de hospedagem onde o servidor mora. E lá, nos tickets, encontramos um aviso sobre "trabalho técnico de X a Y no MSC". O mais interessante é que, nos correios, não importa como pesquisamos, não encontramos nenhuma mensagem do hoster sobre esses trabalhos. O ingresso tinha pelo menos um dia. Antes disso, essas mensagens chegavam ao correio e, normalmente, ninguém olha para os tickets do serviço de suporte (e do próprio escritório do hoster) normalmente sem necessidade especial. Portanto, o que aconteceu foi uma grande surpresa. Depois disso, repreendemos os olhos do hoster, rimos, esperamos até que tudo desse certo e fomos dormir.
Aqui está uma história.