前几天给采集站一次性填充了数万文章，全部计划任务定时发布，结果发现响应居然需要几十秒。并且服务器吞吐量十分巨大，cpu与内存资源占用率非常高，下面是我的排查及优化过程。
第一反应是缓存没生效，比较前几天还好好的，检查了memcached服务，一切正常。然后怀疑缓存空间太小，因为已经达到90%多的占用率。结果提高缓存空间以及开启MySQL查询缓存一样没有效果，但重启缓存后现象仍然存在，基本可以断定问题出在wordpress。
由于添加了大量文章，怀疑mysql查询缓慢，于是给wordpress添加查询记录，debug下查询耗时。在wp-config.php中添加如下内容。
复制
define('SAVEQUERIES', true);然后在footer.php中添加一段输出调试信息的代码。
复制
<?php
if ( current_user_can( 'administrator' ) ) {
global $wpdb;
echo "<pre>";
print_r($wpdb->queries);
echo "</pre>";
}
?>
此代码仅在管理员登录的情况下才输出数据库查询信息。结果如下。
首页存在大量自动加载的查询，查询时间都非常短，不到0.01秒。查询不耗时，但吞吐量大，目标锁定在自动加载的内容上，于是通过mysql执行下面的自动加载数据量查询语句。
复制
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';
结果
WordPress大量计划任务导致响应缓慢
大不大，300多兆。妈的怪不得几十兆的吞吐量都得等好几十秒，问题发现了，处理起来就简单了。
直接禁用wordpress自带的定时任务，然后将这些已经存储的定时任务全删了。这样虽然速度恢复正常了，但定时发布文章的功能没了。
复制
//wp-config.php
define('DISABLE_WP_CRON', true);
删除定时任务，执行MySQL命令。
复制
DELETE FROM `wp_options` WHERE `option_name`='cron';
让GPT给我写一个查询最新的需要发布的计划文章并发布的接口，然后通过Linux的计划任务，每分钟执行一次接口访问即可。
复制
<?php
// 设置WordPress路径
require('wp-load.php');
// 获取最近一篇需要发布的文章
$latest_post = $wpdb->get_row("SELECT * FROM {$wpdb->posts} WHERE post_type = 'post' AND post_status = 'future' ORDER BY post_date ASC LIMIT 1");
if ($latest_post) {
$post_id = $latest_post->ID;
$post_date = strtotime($latest_post->post_date);
$current_time = current_time('timestamp');
if ($post_date <= $current_time) {
// 发布文章
wp_publish_post($post_id);
echo '文章已发布';
} else {
echo '文章不需要发布';
}
} else {
echo '没有需要发布的文章';
}
?>
搞定，采集继续。
评论 （1）