当前位置: 首页>>建站开发>>正文


为什么Drupal 7这么慢?

webfans 建站开发 , , 去评论

问题描述

我刚刚创建了一个新的Drupal 7网站,加载时间过长。我查看了Google的Speed Tracer,以下是第一页的结果:

URL http://mysite.com/
From Cache  false
Method  GET
Http Status 200
Mime-type   text/html
Total Bytes 
Request Timing  @63757 ms for 3331 ms
Response Timing @67088 ms for 379 ms
Total Timing    @63757 ms for 3710 ms

3710毫秒太多,无法在生产站点上加载主页。

有没有人有相同的经历?我该怎么做才能提高速度?

一个speed-related问题出现在MySQL配置文件中:my.cnf

现在我为InnoDB设置了以下MySQL变量:

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2
set-variable = innodb_flush_log_at_trx_commit=0

所以网站现在很快。但是,有时由于某种原因我不明白,当我加载页面时,该网站给我一个空白页面。刷新几次后,将显示该页面。

我认为InnoDB的超时设置可能是问题。你怎么看?

现在我在这里有一个令人难以置信的等待时间:在http://localhost/mysite/user上10760毫秒:

URL http://localhost/mysite/user
From Cache  false
Method  GET
Http Status 200
Mime-type   text/html
Total Bytes 
Request Timing  @12090ms for 10471ms
Response Timing @22561ms for 288ms
Total Timing    @12090ms for 10760ms

有一些奇怪的事情,因为问题不在于Drupal的Response Time,这是288 ms(我认为合理)但是Request Time,这是10471 ms

为什么Request Time这么长?是什么导致了这个?

这是我的设置和模块:

安装/启用APC并启用Cache pages for anonymous usersCache blocksCompress cached pagesAggregate and compress CSS filesAggregate JavaScript files

我安装了以下模块:

  • blockify

  • ctools

  • google_analytics

  • 国际化

  • languageicons

  • metatags_quick

  • nice_menus

  • omega_tools

  • page_title

  • pathauto

  • site_map

  • 代币

  • 变量

  • 意见

  • 网页表单

  • 所见即所得

  • xmlsitemap

最佳解决思路

目前在某些服务器/服务器配置上,Drupal 7存在一些性能问题。

首先,您可以尝试使用7.x-dev快照来查看是否有任何改进。

这是共享主机,您自己的服务器,本地开发环境吗?

您是否已在同一环境中使用Drupal 6?

您是否启用了基本性能设置,例如聚合css /js?

要做更多的事情,你实际上需要弄清楚究竟什么是慢的,通常有一个特定的瓶颈会减慢整个网站的速度。首先,您可以启用devel.module和查询日志记录,以查看该页面上是否存在任何慢查询。

如果这是您自己的服务器,我强烈建议安装并启用APC。

次佳解决思路

最有可能的是,你正在点击Avoid re-scanning module directory when multiple modules are missing。如果您的安装中缺少某些模块,则会发生这种情况。尝试检查您的系统表:

SELECT name, filename FROM system WHERE type = 'module' AND status = 1 ORDER BY filename

和clean-up任何仍然启用但文件系统中丢失的模块。

总的来说,Drupal 7比Drupal 6更加资源友好和可扩展,除了像这样的一些不幸的回归。

第三种解决思路

它不是drupal,它可能是你的服务器有问题。它的确如此,drupal已经发展成为一种饥饿的资源。但它只有你那样精确。

the fact is that drupal 7 is infact very resource friendly in my experience

我在带有memcache的vps上使用了drupal 7,安装了Apc并且它像任何东西一样飞行。

Drupal 7开箱即用,适用于具有高级缓存功能,反向代理,负载均衡器的大型网站。你会说这会让drupal 6过于飞行,但drupal 6和drupal 7性能之间存在显著差异,并且具有相同的高端服务器设置。

从satring我一直使用drupal超过64 MB的RAM,因此我没有drupal有太多问题。

Drupal 7最初可能让你失望,但鉴于适当的硬件和软件环境,你可以在速度方面做出drupal奇迹。

第四种思路

i18n是一个麻烦的模块,因为它几乎与传递给数据库的每个查询交互。在您的情况下,这可能是一个问题。但它可能完全没问题。其他一些模块也可能存在问题。

我的第一步是performance-updating检查数据库。打开MySQL慢查询日志记录和正常查询日志记录(不在生产​​!!)并在站点上运行一些蜘蛛(或点击20页左右)。为经过身份验证的用户和匿名用户执行此操作。

然后,您可以调查日志。有时只是窥视日志已经显示出许多问题;例如2000多个查询来呈现首页(不是不可想象的!)。或者缓慢的查询被反复击中。

下一步是使用tool such as MySQLsla创建一些有关数据库中发生的事情的报告。

接下来,跟踪哪个模块触发查询。如果您可以将某个有问题的(一组)查询/查询引回到一个模块,请考虑禁用该模块或重写它。

如果这对您没有帮助,请调查某些模块是否与查询交互或更改某些重要行为。例如众所周知,i18n与查询交互,将其他非常精简的查询转换为慢速查询。有机组也是一个这样的模块。

只有当您看到数据库没有问题时,继续在其余的Drupals代码中搜索performance-issues。

第五种思路

我注意到我的所有Drupal 7安装都存在同样的问题:如果你的请求有时需要这么长的it is because the cron tasks

在Drupal 7中,cron附加到用户访问;所以,如果你的cron每隔1或3小时开火一次,你的请求时间会很长。 cron将检查是否有新模块,re-index你的数据库等。

你只需要在外部设置对cron的调用并禁用你的cron。

第六种思路

Drupal 7使用了太多文件。和D6一样,它也使用了太多的SQL查询(与其他CMS相比)。因此,第一次点击可能需要一些时间,特别是当您的磁盘速度较慢且文件不在操作系统缓存中时。

在正常情况下,当缓存可用时,一切都应该没问题。缓存有很多层:操作系统缓存,以避免读取PHP文件,操作码缓存(如APC,默认情况下不启用)以避免re-parsing PHP文件,MySQL缓存避免re-execute多次查询。

第七种思路

根据我的经验,托管服务提供商是Drupal的关键。我会做一些上面列出的调整,但只会略微提升性能。 Boost(和Boost Expire)帮助最大,但在管理方面仍然存在性能问题,甚至崩溃。

我将我的托管从GoDaddy切换到HostGator,现在一切都运行得如此之快!我对GoDaddy的服务非常满意,并且不愿意切换主机,但这确实是关键!我对硬件/内存/等一无所知,所以我不能告诉你哪个特定的规格更好,但它对我有用!

我为多个客户提供服务,现在拒绝在其他任何地方托管。该网站将无法正常运行,我不想进行百万次调整以获得几乎无法接受的东西!

这不是anti-GoDaddy或pro-HostGator的帖子……我只是强调通过改变我的特定主机环境,我获得了显著的性能提升。

第八种思路

退出管理员并确保所有管理员都已注销,这修复了我对匿名用户的响应问题。我正在使用一些基本模块和drupal商业安装。网站不是那么大,它只有2个管理员。但是注意到当管理员被标记为登录时,该网站对于每个人,无处不在约5-10秒。登录或不登录。可能或可能不会帮助每个人,但对某些人来说,可能会解决一些令人头疼的问题。我想知道为什么,如果有人知道。我正在考虑作为管理员,我必须在登录时启用它,它会执行某种re-caching,处理或我不知道的事情。这是我的2美分,希望它可以帮助某人。

第九种思路

我发现这篇文章对你有用。

There should have no negative impact on performance for Drupal or any other web app, provided that PHP 5.3 has been properly configured.

If you’ve done any php.ini configuration whilst using PHP 5.2, be sure to read the cautionary note under GatorJacob’s PHP 5.3 Support “sticky” in this same forum. Failure to clean up any such “EasyConfig” remanants prior to the version changeover is likely to use incorrect paths and other settings that could certainly affect the end results quite drastically.

第十种思路

当开发人员将域名设置为数据库服务器而不是settings.php中的数据库服务器的主机名时,我在生产服务器上遇到了这个问题(10秒到第一个字节)…

小心!

参考资料

本文由朵颐IT整理自网络, 文章地址: https://duoyit.com/article/2402.html,转载请务必附带本地址声明。