【问题标题】:Wordpress slow meta query on 1000+ postsWordpress 对 1000 多个帖子的慢元查询
【发布时间】:2015-03-13 08:25:27
【问题描述】:

问题

就选择日期而言,WordPress 元查询不如常规查询灵活。 WP Query 可以通过月份编号、星期几名称和许多其他选项来选择日期,这非常适合我的需要。

ACF 字段

事件日期、结束日期、死亡日期(某些分类法)、“重复(永远,直到)”

基本上,我构建了一个元查询,它将获取今天登陆的日期,或者可能会重复出现的日期(因此每天、每月和每周),然后我通过 PHP 通过与每周的工作日名称进行比较来过滤所有内容,并且每月的天数。我还会检查以确保任何重复发布的帖子都不会在不应该出现的时候出现。

这是我一直使用的元查询数组,日期存储为Ymd

'relation' => 'OR', [ 'key' => 'event_date', 'value' => $date->format('md'), 'compare' => 'LIKE', 'type' => 'numeric' ], [ 'key' => 'death_date', 'value' => $date->format('md'), 'compare' => 'LIKE', 'type' => 'numeric' ], [ 'key' => 'how_often', 'value' => array('Daily', 'Monthly', 'Weekly'), 'compare' => 'IN' ]

从长远来看,这个查询将检索大约 130 个帖子,包括元和其他相关查询,并且在 PHP 运行过滤帖子之后(需要 2.5 秒!)我剩下 78 个帖子。

我的尝试

我已经尝试通过非常具体地针对重复发布的帖子来限制查询,例如指定event_date 必须是<= 查询日期,并且end_date>= 查询日期或元forever 设置为forever。但是,当涉及到每月或每周重复时,这将无济于事,因为我无法切实计算这些日期。我已经加载了超过 10k 个帖子并使用了这个自定义元结构。它运行良好,最多有大约 1200 个帖子,然后网站变得非常缓慢。包含 78 个帖子的页面目前加载第一个字节大约需要 8-12 秒。

我已尝试缓存此数据,但有人可能会点击日历中的任何一天,并且它可能不会被缓存,这将导致用户在看到来自该站点的任何内容之前被阻止 8-12 秒。

问题

  1. 通过 SQL 检索每月和每周周期性帖子的最佳方法是什么?
  2. 这实际上会加快我的页面加载速度还是减慢速度?显然,随着帖子越多,对元数据的查询就越多,但分页并不是这个应用程序的真正选择。

【问题讨论】:

    标签: mysql performance advanced-custom-fields wordpress


    【解决方案1】:
    1. 我没有加快查询速度的解决方案。在 WordPress 中分配大量数据时,它会减慢加载/查询速度。无论你会做什么,它仍然会超过 2 秒 +。 (已经太多了)。

    2. 关于缓存选项,您可以构建一个机器人来访问所有链接,因为日期范围是已知的,然后问题就解决了。类似的东西:(这只是一个例子)

       for($startdate ; $startDate < $endDate ; $startDate=addDayToDate($startDate)){
            file_get_contents($url.$startDate);
       }
      
    3. wp-rocket 缓存插件可以选择由机器人预先缓存页面。所以不需要真正第一次访问页面来缓存它。关于日历链接,我不知道它是否会访问它们,以及是否有办法设置预缓存机器人来访问您的日历链接。如果你能提供一个链接,我可以问他们是否可能。

    【讨论】:

    • 感谢您的建议,但我认为机器人会很快杀死服务器。
    【解决方案2】:

    对于这么少的帖子,它真的不应该花费 2.5 秒。你需要看看你的主机。要查看的内容包括您在此页面加载时的内存使用情况 - PHP 迭代 130 多个项目并过滤到 75 个帖子应该需要几毫秒。

    如果您使用的是 Apache,请考虑切换到 Nginx - 它的内存使用量要轻得多,如果这是基于内存的减速,您会发现速度显着提升。

    【讨论】:

    • 该站点在它自己的云 VPS 上,带有 2 个 CPU 和 4gb Ram + Nginx,所以我不认为它是那样的。我已将其范围缩小到更接近 mysql 和查询以及查询 wordpress post-meta 很糟糕的事实!
    • 如果你确定是 mysql 那就太糟糕了,但我个人还没有看到这么小的表有那么糟糕的性能。看看rugbydata.com - 它是带有 2 个 CPU 的 Wordpress,我认为 4GB RAM 也可能是 2GB,并且 Nginx 配置正确。帖子表中的条目比 100 多。您可能想看看设置 New Relic 以真正找到性能问题的根源,或者快速设置 HHVM - 需要 5 分钟,并且可能是您的性能提升一直在为 - affiliatewebdesigners.com/2015/01/14/setting-hhvm-wordpress
    猜你喜欢
    • 2017-07-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-07-05
    • 2021-09-27
    • 1970-01-01
    相关资源
    最近更新 更多