而是，本文来自一系列“女主人笔记”。 好吧，关于个人经历和欺诈的更多信息。
如果您必须处理安装了WP Super Cache缓存插件的WordPress网站，那么本文可能对您有用。 否则，这只是一个简短的故事。
简而言之，故事的开始是这样的：有一个站点。 专题新闻和信息。 由CMS WordPress上的未知向导制作。 并完全按照其所有者当时允许的方式进行。 随着时间的流逝，该网站越来越受欢迎，访问者的数量也在增加。 该网站本身在广告中“赚了”。 即 访客越多越好。 有时，在高峰时段，网站开始上交：页面加载缓慢等等。 但是，当然，在公鸡啄之前，没有人真正动过。 这只公鸡出现在该地点本应涵盖引起公众注意的事件的那一刻。 访客跑了进去，该站点瘫痪了，所有的估计收入都在我们眼前熔化。 由于情况的缘故，我不得不担任复苏者。 那时我写
了一篇关于这个
的文章 。 我的决定令人毛骨悚然（不重复），但主要目标得以实现-梦想得以保存。 通常。
当然，没有人有兴趣重复类似的情况并在该网站上工作。 首先，他们找出了服务器下降和高负载的原因。 它们是司空见惯的：缺少这样的缓存站点，以及记录和显示文章视图数量的机制实施不当。 后者本身造成了很大的负担：每次请求文章页面时，他都会从数据库中获取该文章的视图数，进行显示，然后添加一个视图并将其写回到数据库中。 同时，带有元数据的
wp_postmeta表用于存储（似乎在WP中被调用）。 大量存储的数据与会计信息视图完全无关，并且非常大。
缓存问题的解决很简单：在安静的环境中，WP Super Cache插件已正常安装。 如果我没有记错的话，很多事情建议我做，而不是我在那篇文章的评论中建立的怪异拐杖。 老实说，我那时和现在在WordPress生态系统中的导航不畅，因此出现了拐杖。 缓存插件是由已经认识的人安装和配置的，它可以立即使用。 因此，解决了缓存问题。 为什么选择这个插件，我不确定。 据我了解，这是WP这类最受欢迎的插件之一。
鉴于这些观点，他们的行为有所不同。 显然，必须放弃原始机制。 我不想拒绝考虑自己的观点：至少有一个与“本周最受欢迎文章”类似的图块与之相关。 事实证明，所有用于记录视图的插件（即使它们与缓存插件是“朋友”）都非常繁琐，并且通常在从wp_postmeta写入和提取数据时实现相同的机制。 对于小型站点，这是非常合适的。 对于峰值出勤率相当稳定的站点-不再：对于如此小的功能而言过于繁琐。 然后，顺便说一句，我开了几年的付费和未使用托管服务。 最简单，最便宜的。 他负责存储，记录和返回有关视图的数据。 一切都是异步的，即 即使跌倒了，主站点也将继续安静地显示文章，广告以及应显示的所有内容。 查看数据的在线存储分配给Redis，长期存储分配给MySQL。 因此它正在旋转，它并没有真正要求，并且占用了该主机上允许的最大负载的1-2％。
因此，很长一段时间过去了。 一次又一次的老故事。 相当大的流量进入该站点，该站点开始崩溃。 再说一次，我是该地区唯一清醒的条件专家。 当然，我对事件的重复感到惊讶。 我的第一个想法是有人不小心关闭了缓存。 但是不，在故障服务器提供给我的站点页面的源代码中，我看到了缓存插件起作用的迹象。 一切都应该没事。 但是在服务器控制面板中，我看到没有剩余的RAM，数据库查询的数量令人难以置信，并且一切都不好。 首先，我打开带有插件说明的页面，快速浏览她的眼睛，一无所获，然后退出此活动。 下一步是查看统计信息。 我看到主要的流量从Yandex.Zen涌入该站点。 将用户引导到站点的请求如下所示：
https://example.com？utm_referrer = https：％2F％2Fzen.yandex.com
即 Yandex.Zen将其utm标签添加到该地址。 由于服务器已经完全瘫痪，只能给我500个服务器，因此由于某种原因，我无法明确地验证没有缓存具有这种“权重”的页面的理论。 因此，另一个“拐杖”诞生了（后来被替换了）：.htaccess中添加了重定向，它将带有utm标签的请求转换为没有WordPress的请求，而WordPress及其所有强大的插件才起作用。 机器重新启动，瞧，一切正常：站点快速加载，服务器以低速安静地沙沙作响。 什么也没发生。
然后我放松下来，平静地看着缓存插件的设置。 首先，存在“不使用GET参数缓存页面”复选框。 一切都很好，她不值得。 另外，如实验所示，该插件可处理带有任意一组任意参数的查询缓存。 如果这些不是utm标签（实际上，我仅重定向了某种类型的请求，而没有剪切所有utm标签）。
在这里，我仔细地（使用CTRL + F）查看了插件页面。 我在FAQ中找到了一段光彩的段落：“如何最好地将此Google Analytics（分析）中的utm_source跟踪工具与此插件一起使用？”。 很明显，在第一次粗略的检查中，我放心地忽略了他：似乎与这个问题无关。 顺便说一下，与此同时，它不是很实用，也没有提供任何特定的解决方案。
本文中唯一可能有用的结论是：如果您的WP站点带有WP Super Cache插件，则检查其作用（或没有作用），如果您提交的请求参数为“？Utm_referrer = https：％2F％2Fzen。 yandex.com”等 我不确定在安装此插件时，每个人是否都会仔细阅读其常见问题解答。 显然，具体的实现仍由站点所有者拥有：当我上一次查看此插件的更新时，关于其对utm标签的奇怪反应，我没有看到任何变化。
但是，如果没有其他关于墨菲定律的确认，这个故事将是不完整的（我不会告诉你）。 当我们与站点所有者和平地通信时，看着站点如何安静地运行了大约一个小时……站点崩溃了。 没想到，最后。 无法访问服务器控制面板，FTP，SSH，其他所有功能均不起作用。 没用。 如果在那之前，通过解决J. Zen和缓存插件引发的问题，我的压力只是稍有增加（毕竟，能快速轻松地理解并解决某些问题，这是一种特别的荣幸），那么整个迷你恐慌就会发生在我身上。 而且只有模糊的感觉，即.htaccess中的几行代码在制作完这些代码行一小时后无法杀死所有内容，并没有使“ mini”变成更完整的内容。 通常，在交换令人惊讶的消息几分钟后，我们进入了服务器所在的托管服务提供商的个人帐户。 在票证上，我们发现了一条警告：“在MSC上从X到Y的技术工作”。 最有趣的是，在邮局中，无论我们如何搜索，都没有发现托管人关于这些作品的任何消息。 门票至少有一天的时间。 在此之前，此类消息是通过邮件发送的，通常没有任何人通常在没有任何特殊需要的情况下查看支持服务的票证（以及托管人办公室本身）。 因此，发生的事真是令人惊讶。 之后，我们责骂主持人的眼睛，大笑，等到一切正常并入睡。
这是一个故事。