加载时间与admin-ajax.php相关的问题(使用PINGDOM结果链接)

时间:2014-03-28 05:51:06

标签: php ajax wordpress pingdom

我正试图让我网站上的加载时间缩短。它的加载速度非常慢,iv尝试了几种解决方案。

  1. 使用gmetrix解决优化图像等问题。
  2. 使用pingdom查看问题所在。
  3. 以下链接中列出的是pingdom统计信息。 http://tools.pingdom.com/fpt/#!/cKIvOz/http://healthyeatingandliving.ca/

    我不知道admin-ajax.php是什么以及为什么负载如此之高。此外,如果有人知道文件/路径列中的第一行是什么。

    如果还有其他任何工作可以让加载时间减少,那么现在很难尝试编辑内容。  感谢所有关注此事的人。

4 个答案:

答案 0 :(得分:3)

您应该将此代码添加到主题中的functions.php中。

add_action( 'init', 'my_deregister_heartbeat', 1 );
function my_deregister_heartbeat() {
    global $pagenow;

    if ( 'post.php' != $pagenow && 'post-new.php' != $pagenow )
        wp_deregister_script('heartbeat');
}

此代码将禁用admin-ajax.php功能并将CPU降低75%。

答案 1 :(得分:1)

ajax加载时间的问题是即使您在某些页面上没有商店所需的任何功能,也会运行woocommerce脚本。我会考虑这些人做了什么,并从常规页面删除脚本(抱歉网站有点旧,所以你可能想要仔细检查和更新排队脚本变量)。但要获得它的要点,你基本上将删除对于不需要woocommerce功能的页面不必要的插件。

http://wordimpress.com/how-to-load-woocommerce-scripts-and-styles-only-in-shop/

http://gregrickaby.com/remove-woocommerce-styles-and-scripts/

您还可以添加一些条件标记,以便它不会在某些页面上加载。

https://codex.wordpress.org/Conditional_Tags

答案 2 :(得分:1)

另一个插件或主题是使用类似购物车小部件的东西,当您添加到购物车等时刷新,这使用admin-ajax并将加载到每个页面,如果您停用WooCommerce然后问题消失但问题是某事这取决于WooCommerce。

答案 3 :(得分:1)

我花了几天时间试图解决同样的问题,我甚至使用了deregister_heartbeat代码 - 没有效果。我想分享一个解决方案,以便在你试图找出正在发生的事情的同时防止Apache / MySQL死亡。

最后在另一台服务器上创建网站的测试副本并交换到默认主题后,我能够发现子主题中的扩展引擎正在进行Ajax调用以某种方式超越了注销的心跳 - 我们现在放弃了引擎,可能会从头开始编写儿童主题。

为了给我带来一些时间跟踪有问题的东西,我需要一种方法在网络服务器占用所有可用空间之前从网络服务器中删除线程 - 我们有一个很大的网络服务器 - 它仍然导致网站在一小时后崩溃自Apache重启以来。您当然可以在Debian计算机上使用硬重启Apache( apachectl restart 服务apache restart ) - 但这会终止所有连接 - 并且在多主机环境中打算搞砸一个人。如果您使用的是* NIX系统,则可以执行以下操作,它需要 w3m (或等效的 braile-mode 浏览器,可以从CLI运行转储,如elinks,lynx或链接)

#!/bin/bash
kill `w3m -dump http://<server address>/server-status | grep "admin-ajax.php"|awk '{print $2}'`

确保在kill和脚本结束后立即获得反引号。我们基本上使用w3m来访问服务器状态页面(你需要在你的Apache配置中启用它 - 只能从本地IP地址使用它,它提供了很多) - 我们通过grep管道结果只是磨练处理 admin-ajax.php 的流程 - 然后我们将这些行提供给 awk ,它基本上返回一个关联的 PID 数字列表 kill 命令。

结果是Apache中的进程线程将死掉 - 但是在任何服务器状态列表中会显示一段时间打开插槽而没有当前进程 - 后续点击到您的站点将占用这些线程再次以正常方式再次出现

我们将整个事情放入每5分钟左右运行的 cron 任务中 - 效果是我们让线程出现了,但是它们从来没有停留足够长的时间来导致问题。