为什么主页比其他页面慢(很多)?

时间:2010-09-11 作者:Matteo Riva

我正在尝试调整wordpress网站,该网站的加载时间很慢,我发现主页的加载时间似乎要长得多。这不是因为内容,因为我只是在考虑基本请求结束所需的时间(可通过firefox中的firebug查看)。

我还尝试复制索引。php代码位于自定义页面中,相同的代码大约在1秒钟内加载,而主主页大约在7秒钟内加载。我注意到单页加载速度更快,起初我认为这是由于内容的不同,但在这次测试之后,我不确定是什么原因造成的。

wordpress在幕后只为主索引做了很多事情吗?有没有其他方法来解释这种情况,更重要的是,修复它,以便主页加载更快?

UPDATE -- DIRTY SOLUTION

经过多次盲目尝试,我创建了一个名为home的新页面,该页面使用index.php 作为自定义模板(不是副本,是同一个文件)。我将所有调用重定向到它的基本路径(通过wordpress的内部重写),我的主页和以前一样,只加载了六分之一的时间。虽然我对结果很满意,但我真的很想了解到底发生了什么。

ANOTHER UPDATE

所以重点似乎是,我不能在这个网站上使用动态(wordpress意义上的)页面,它只适用于自定义的“静态”页面,我通过各种功能插入内容,正常的循环使主页要么非常慢(内存限制很高),要么就是空白(内存限制很低,脚本失败)。

正如在this question, 我创建了一个链接到自定义页面的静态主页,效果很好。我还创建了一个博客页面(同样使用自定义模板),该页面也可以正常工作(其中“fine”表示它显示的是我的空测试页面,只包含一个单词,没有代码)unless 我在管理->阅读设置中将其指定为“帖子页面”。换句话说,wordpress一看到动态页面(应该包含主循环的页面)就会执行一些非常繁重的操作,这会消耗大量ram。

仍然在寻找原因,我可以解决它,但我真的很想了解问题是什么。

编辑:添加悬赏

更多信息:我尝试禁用所有插件,wordpress已更新至最新版本。

FURTHER EDIT: TABLE INDEXES

wp\\U帖子:

PRIMARY KEY  (`ID`),
KEY `type_status_date` (`post_type`,`post_status`(1),`post_date`,`ID`),
KEY `post_status_date_gmt` (`post_status`(1),`post_date_gmt`),
KEY `post_date` (`post_date`),
KEY `post_date_gmt` (`post_date_gmt`),
KEY `post_parent` (`post_parent`),
KEY `post_name` (`post_name`),
KEY `post_status` (`post_status`),
KEY `post_author` (`post_author`),
FULLTEXT KEY `post_related` (`post_name`,`post_content`),
FULLTEXT KEY `post_content` (`post_content`,`post_title`),
wp\\U term\\u关系:

PRIMARY KEY  (`object_id`,`term_taxonomy_id`),
KEY `term_taxonomy_id` (`term_taxonomy_id`)
wp\\U term\\u分类法:

PRIMARY KEY  (`term_taxonomy_id`),
UNIQUE KEY `term_id_taxonomy` (`term_id`,`taxonomy`),
KEY `taxonomy` (`taxonomy`)

5 个回复
最合适的回答,由SO网友:Matteo Riva 整理而成

将近4年后,我重新开始,终于找到了问题所在。原来该网站有很多文章都标记为粘性。由于wordpress用于标记粘性帖子(wp\\U选项中的序列化数组)的方式愚蠢得令人难以置信,动态主页的主循环花费了难以置信的时间。正在清除sticky_posts 表中的字段修复了该问题。

SO网友:Denis de Bernardy

我不同意前两条评论。

使用静态主页会导致在posts表的主键上使用索引扫描,而在posts表中的post\\u日期、状态或post\\u父级上使用索引扫描(偶尔)。

本质上,由于WP中糟糕的数据库设计,主页速度非常慢。该模式在分类表上有可笑的多列索引,一旦有大量帖子,MySQL就会忽略这些索引。我们在分类法中使用了太多的表这一事实也没有帮助。

在数据库中,安全地在以下对象上添加索引:

CREATE INDEX extra_posts ON posts (post_type,post_status,post_date DESC)
CREATE INDEX extra_term_rel ON term_relationships(term_taxonomy_id,object_id)
CREATE INDEX extra_term_tax ON term_taxonomy(taxonomy,term_taxonomy_id,term_id)
这并不完美,但至少WP能够在头版使用基于索引的嵌套循环计划。。。

哦,还有。。。如果您在首页上使用任何类型的自定义帖子类型,您还需要添加:

posts(post_status,post_date DESC)
否则,由于OR子句的原因,将不会对主查询使用任何索引。

SO网友:Rarst

默认情况下,主页的性能并没有任何差别。然而,有可能某个插件单独在该页面上做得很慢。

有很多插件可以分析WP的性能。我通常用WP Tuner 但它似乎是打破了最新的WP版本,所以我没有立即更换建议。

最简单的方法是将模板中的时间/内存标记打包。

printf(  \'%d queries in %.3f seconds, using %.2fMB memory\', get_num_queries(), timer_stop( 0, 3 ), memory_get_peak_usage() / 1024 / 1024 );
这是一种粗糙的方法,但通常可以精确定位减速发生的位置。

SO网友:prettyboymp

如果加载主页需要很长时间,则很可能主题中有一个插件或函数在主页呈现时发出远程请求。

我会在您的wp内容目录中递归搜索对“wp\\u remote\\u”的调用,以查找可能导致此问题的任何函数。

SO网友:bueltge

首先,检查WOrdPress的查询以及包含的图像、脚本和样式表。您可以使用插件检查查询Debug Queries 您可以了解更多关于您的安装和插件错误的信息Debug Objects.

结束

相关推荐