在本教程中，我将向您展示如何通过在 Linux 上用 Crontab 替换默认的 WP-Cron 触发机制来优化 WordPress 性能。
WordPress 使用 WP-Cron 来运行计划任务，许多用户已经在使用。
但它的工作方式并不理想。
在每次页面加载时，WP-Cron 检查计划任务列表并执行任何应运行的任务。
通过页面加载触发定时任务有两个弱点：
1.可能会影响页面加载速度
2. 不确定的时间表——例如，任务 A 计划每小时运行一次，但在六个小时内没有页面加载。任务 A 仅在六个小时后执行。
换句话说，我们需要一种更好的方式来触发不依赖于页面加载的 WP-Cron。最好的解决方案可能是使用系统级调度程序，例如 Linux cron。
目录 隐藏
如何通过将 WP-Cron 委托给 Linux Cron 来优化 WordPress
如何通过将 WP-Cron 委托给 Linux Cron 来优化 WordPress
在本节中，首先我将向您展示如何禁用在页面加载时触发 WP-Cron。然后我将与您分享几个可用于手动运行 WP-Cron 作业的命令，以及如何通过 crontab 文件将这些命令连接到 cron。
在文章的最后，我们将介绍一些有关如何验证您的设置的提示，以及一些在您遇到任何问题时会派上用场的故障排除技巧。最后，我将通过简要讨论什么是 WordPress 的最佳 cron 作业频率来结束本文。
快速链接
- 停止 WP-Cron 自动运行
- 准备空的 Crontab
- 将 WP-Cron 委托给 Crontab 的 3 种方法
- 1.使用PHP在本地执行wp-cron.php
- 2.使用 WordPress 命令行工具 WP-CLI
- 3.使用wget通过HTTPS访问wp-cron.php
- 如何验证您的 WordPress Crontab 正在运行
- Crontab 故障排除提示
- WordPress 的最佳 Cron 作业频率
停止 WP-Cron 自动运行
首先，停止 WP-Cron 自动运行。这是通过将以下行添加到 wp-config.php 中来完成的：-
准备空的 Crontab
忘记 crontab -e，管理 Linux cron 作业的最佳方法是通过 crontab 文件。
在 /etc/cron.d 下为 WP-Cron 任务创建一个新文件
这个 wp-cron 文件（或者你给它起的任何名字）将在下一节中使用。
我将此文件称为“cron 文件”或cron 表文件的“crontab”。
将 WP-Cron 委托给 Crontab 的 3 种方法
有几种方法可以执行 WP-Cron 任务。
以下是您可以使用的三种不同方法以及有关如何将它们连接到 cron 的说明。
1. 使用 PHP 在本地执行 wp-cron.php
第一种方法是直接调用PHP在本地运行wp-cron.php。
您可以从终端运行此命令以查看是否有任何错误。只要知道如果没有任何问题，该命令将不会提供任何响应。
在我们在上一节中创建的 cron 配置文件中，添加以下行。
* * * * * 表示该命令每分钟运行一次。
下一段指示 Cron 以用户身份运行作业www-data。
php /var/www/html/wp-cron.php是要运行的命令。/var/www/html/是您的 WordPress 根目录的完整路径。
/dev/null 2>&1告诉 Linux 将输出消息发送到遗忘 (/dev/null)，因为我们不关心命令的输出消息（如果有的话）。在下面的故障排除部分中有更多相关信息。
如果您托管多个 WordPress 网站，只需在文件中添加另一行并更改路径即可。例如，
如果 cron 抱怨找不到 php，您可以尝试在 PATH 变量中直接显式设置 PHP 二进制文件的路径，例如
优点
- 三种方法中最快的方法
- 在本地运行——这意味着不再需要外部访问 wp-cron.php 并且可以在防火墙中被阻止以防止恶意攻击。
缺点
- 安全问题。即使它由用户 www-data 运行，直接在 wp-cron.php 上调用 PHP 也可能允许恶意用户访问服务器上可由 www-data 访问的其他位置。但是，风险级别应该是最小的。
- 潜在的 PHP 版本差异。即 NGINX / Apache 使用一个 PHP 版本，但 /usr/bin/php 可能是不同的 PHP 版本。但是，通过正确检查您的设置可以轻松解决此问题。即使您不这样做，也不太可能引起问题。
- 如果网站路径更改，则 Cron 文件需要更新
2. 使用 WordPress 命令行工具 WP-CLI
对于第二种方法，我们将使用 WordPress 的官方命令行实用程序，即 WP-CLI。
首先，将它安装在您的服务器上并验证它是否正常工作。
接下来，使用此命令手动运行计划的 WordPress 任务：-
--path='/var/www/html'指定 WordPress 安装的完整路径。没有它，您将首先获得到 WordPress 路径的 cd，这对于 cron 作业来说并不理想。
如果您遇到错误，这里有一些资源可以帮助您解决错误：-
- 如何修复 WP-CLI 错误：奇怪的 wp-config.php 文件
- 故障排除提示部分
准备就绪后，通过在您之前创建的 wp-cron 文件中添加以下说明来设置 cron 作业。
首先，PATH=/usr/bin:/usr/local/bin为该文件中定义的作业设置 PATH 环境变量。
我们需要这个的原因是因为默认情况下，WP-CLI 安装到 /usr/local/bin 可能不在默认的 cron PATH 中。
没有它，您可能会收到类似 /bin/sh: 1: wp: not found 的错误。
* * * * *指示 cron 每分钟运行一次。
www-data是将运行作业的用户。
然后我们有我们之前讨论过的 WP-CLI 命令。其次是> /dev/null 2>&1隐藏输出消息。
这是多个网站的 crontab 示例：-
优点
- 快速地
- 在本地运行——这意味着您可以通过在防火墙中阻止 wp-cron.php 来防止它受到恶意攻击。
缺点
- 依赖项：PHP 和 WP-CLI
- 不更新 crontab 就无法更改网站路径。
- 需要更多的工作来设置它
- 安全性：未知，但可能比 PHP 方法更安全或与 PHP 方法一样安全。不幸的是，我对 WP-CLI 的内部工作了解不够，无法对此发表评论。
3.使用wget通过HTTPS访问wp-cron.php
最后一种方法涉及使用 wget 或 curl 等程序通过 HTTPS 从外部调用 wp-cron.php。我将在此示例中使用 wget，但您可以切换到 curl 并获得类似的结果。
首先，这是手动操作的方法。
--delete-after最后告诉 wget 删除下载的文件。
https://exampe.com/是 WordPress 站点的 URL。wp-cron.php?doing_wp_cron是用于触发和运行计划作业的 WordPress 端点和参数。
示例 cron 文件：-
* * * * *, www-data, 和mean的解释请参考上一节> /dev/null 2>&1。
您应该能够在 crontab 中调用 wget 而无需指定 PATH 并使用绝对路径，但如果您遇到任何问题，请查看故障排除部分以获取一些提示。
优点
- 最接近 WP-Cron 最初的做法。
- 在官方 WordPress示例中使用。
- 最容易设置。
- 可能是三者中最安全的。
- 独立于机器——您可以从外部服务器管理 cron 计划。
- 几乎没有依赖性——您不必担心 PHP 二进制版本差异、WP-CLI 过时或更改 WordPress 目录。
缺点
- 与其他方法相比，速度较慢且需要更多资源——当您在托管 WordPress 网站的同一台机器上执行此操作时。
- 最终，wp-cron.php 是从外部触发的——这意味着您无法在防火墙中阻止外部访问 wp-cron.php。解决方法：阻止对 wp-cron.php 的访问，但将触发服务器列入白名单。
如何验证您的 WordPress Crontab 正在运行
首先，安装一个 WordPress cron 监控插件。我一直在使用 WP-crontrol，它对我很有帮助。
该插件向您显示在内部 WP-Cron 系统中排队的作业、它们的频率（重复出现）以及它们应该在何时运行。
还要注意屏幕顶部显示 DISABLE_WP_CRON 设置为 true。那就是你想看到的。这意味着 WordPress 将不再尝试在页面加载时触发计划任务。
如果您的 crontab 设置不正确，WP-Crontrol 将通过突出显示错过其计划的任务（事件）来通知您：-
Crontab 故障排除提示
这里有一些技巧可以帮助您找到与 cron 相关的问题的根本原因。
1.查看系统日志
Cron 相关的消息记录在 /var/log/syslog
输出片段：-
在上面的输出中，第一行告诉我们，我们制作的自定义 crontab 文件被 cron 识别。
倒数第二行显示我们在 crontab 中定义的命令每分钟执行一次，如时间戳所示。
这表明问题可能来自命令本身或设置不当的 cron 环境。
2. 记录命令输出
/dev/null 2>&1将 STERR 发送到 STDOUT，然后发送到 void。这在对输出消息不感兴趣时很有用。
出于调试目的，将输出记录到文件中。例如，
此指令将所有输出消息附加到 /tmp/last-cron.log。
然后，您可以根据在该文件中找到的信息进一步排除故障。
3.显示Cron环境
我发现另一个有用的技巧是在 crontab 中添加一个命令来显示环境变量。
使用 printenv 打印环境变量并将其保存在日志文件中：-
/tmp/last-cron.log:-
这将向您展示 cron 守护进程正在使用什么样的环境来运行您的命令。
4.最常见的错误
根据我的经验，错误定义的路径通常占 cron 错误的 90%。
这个问题有两种解决方案。
一种是始终在 crontab 中使用绝对路径。
二是明确定义您的 crontab 的 PATH 变量。
例如，如果您既没有定义 PATH 也没有为 WP-CLI 方法使用绝对路径，您将收到此错误：-
通过从 cron 任务调用 printenv（见上一点），我们可以看到这是 PATH 设置：-
但是，wp 位于不在 PATH 中的 /usr/local/bin 下：-
一种解决方案是在您的 cron 指令中使用绝对路径：-
另一种解决方案是将 /usr/local/bin 添加到 PATH：-
WordPress 的最佳优化WP-Cron 作业频率
根据您的 WordPress 计划任务的要求，最佳频率尽可能低。
例如，假设这是您的 WordPress 事件的样子
最频繁的事件/任务是 wp_privacy_delete_old_export_files，它设置为每小时运行一次。这表明您可以将 crontab 频率设置为每小时一次而不会影响任何事情。
然而，这项任务似乎并不那么重要。我的意思是“删除旧的导出文件”对我来说似乎不太重要。多等几个小时应该没问题。
另一方面，recovery_mode_clean_expired_keys 听起来像是一项关键任务。它的频率是每天一次。我们可能不想延迟太多。这表明如果你想真正优化你的 cron 作业，你可以指示 Linux cron 守护进程每天触发一次 WP-Cron。
仅供参考，我将我的设置设置为每分钟运行一次，因为这是最简单的，并且适用于我所有的 WordPress 设置。
373
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
