欢迎各位兄弟 发布技术文章

这里的技术是共享的

You are here

drupal page execution time high google 谷歌 "drupal page execution time high"

shiping1 的头像

页面执行时间要比执行查询时高得多。但为什么?

 

 

嗨,

我在网上做社交网络/社区网站...基本上类似于MySpace的过程....我最近从共享主机到VPS,(原因很明显)移动。这是Debian Etch3盒128 MB RAM破裂的为256 MB .....这就是现在,我会得到额外的256 MB的RAM下个月。我设置Apache / 2.2.3 PHP / 4,Mysql5的,e​​Accelerator在0.9.5

我所关注的大多是现在网页的执行时间。首先,我认为MySQL的很慢,但现在我不知道....例如,对于在头版,我得到:

在774.35毫秒为单位执行80查询。查询时间超过5毫秒和查询执行多次,被突出显示。页面执行时间为2060.83毫秒。

FrontPage是大部分地段板,其中一些显示缓存块,他们中的一些随机显示SQL结果。为什么查询在0.7秒执行,并且页面执行时间为2秒??? 这无疑已成为一些与Apache的配置或PHP配置。

在php.ini我设置了memory_limit为64M,
对于eAccelerator在我设置为SHM 32M。

我真的想搞清楚为什么会出现查询执行时间和页面执行时间之间如此大的差异....页面执行时间应大于查询执行时间高了litlle位,对不对?

所以,如果你对我有任何指针到哪里寻找解决方案,我会比感激你。

提前致谢

ķ。

注释

 

NancyDru的图片

 

我检查的第一件事是php是否真正得到64M(这是一个有点高,但还好)。很多主机厂商使用的是没有覆盖memory_limit的能力编译一个PHP。作为事实上,我的主人完全忽略了我的php.ini的settings.php和两个(至少如内存和执行时间设置)。

此外,在无耻的自我推销的情况下,我建议网站的文件模块,以寻找可能有点问题。

南希W.
Drupal的食谱(新Drupallers)
添加隐藏式设计,或在你的数据库如何笔记

dawehner’s picture

 

好了,phpinfo()函数说,memory_limit的为64M,就像我设置它。您的意思是要检查这种方式还是其他方式?

顺便说一句我只注意到我有很多PHP模块启用,以及...像:bcmath,BZ2,日历,CTYPE,DBA,DBX等..不知道如果我需要这一切,如果禁用某些人会减少页面的执行时间。

我在其他线程读取有关的另一件事是尝试,把.htaccess文件里面apache2.conf,所以所有的规则都加载一次当Web服务器启动,而不是在每个页面加载。会尝试,是肯定的。

任何其他建议多于欢迎。

ķ。

yelvington的图片

 

... PHP执行开销。你肯定eAccelerator在正常工作?

您可以尝试将其打开/关闭,或切换到APC,看看是否有一个显著的差异。

dawehner’s picture

 

这极有可能是php开销.... eAccelerator在工作正常..我试图把它关闭,我得到了更高的网页执行时间。

有点奇怪。当你点击一个链接到加载一些页面,这使得1〜2秒钟的停顿,然后继续加载的页面。看到它自己:http://tranceplanet.org/ 并尝试点击一些链接。

的phpinfo是http://tranceplanet.org/info.php

顺便说一句我降​​低了memory_limit在PHP中32M

NancyDru的图片

 

我去你的网站,它加载相当快的我。由于繁忙的头版,我很惊讶,这不是需要更长的时间 - 特别是查询。

南希W.
Drupal的食谱(新Drupallers)
添加隐藏式设计,或在你的数据库如何笔记

dawehner’s picture

 

80查询在700毫秒仍然很高。下面是我得到在Xen VPS(512MB虽然,但这不应该的问题):

在92.61毫秒执行的269查询。页面执行时间为349.69毫秒。

你似乎是对的Virtuozzo(或OpenVZ的),其性能被称为没有好。我提出谁下的Virtuozzo遭受客户Xen或敬业,他们已经幸福。我甚至关内外交通,做了测量,证明给客户端,它的Virtuozzo,而不是从访问者点击率,是造成减速。

我敢打赌,这就是问题所在,但这里有其他建议。

我曾经看到过类似的事情,在PHP倍比查询时间要多得多,而且几乎总是由于流浪模块。

4.6,它使用的是当你有很多别名(千),和Drupal试图加载它们都在一个关联数组。

但是,你似乎是运行4.7,所以这不会是问题。

其他的事情来看看:

- 你有没有打开插座到其他网站的模块?

-尝试安装跟踪模块,看看时间花费。

Drupal的开发和定制:2bits.com
个人:Baheyeldin.com


Drupal的性能调整和优化,托管,开发和咨询:2bits.com,公司和Twitter的:@的2位
个人博客:

dawehner’s picture

 

- 是的,我刚查了,我是在OpenVZ的同时....他们补充更多的RAM我的VPS,所以它现在是512 MB。

- 我想APC一个小时前,但似乎它的性能比eAccelerator在差,所以我放回eAccelerator在。

- 我中运行D 5.1

- 我不知道是什么流浪模块?

-是的,我确实有很多网址别名(我想我申请的补丁,从这里:http://drupal.org/node/100301

- 我没有打开插座到其他网站的任何模块。

- 我会跟踪模块等明天的东西,玩althought我不会满足,直到我做到有较低的网页执行时间。

谢谢。

dawehner’s picture

 

是否有D中5.1跟踪模块,任何其他的选择吗?我怎么能看到是大多数页面执行时间用在何处?也许尝试的Xdebug和调试我的PHP脚本?

或者也许很多网址别名放缓的网站了吗?我有一个网站没有所有那些花哨的网址别名,如果我知道页面执行时间会更高。

我可能会关闭部分模块,以及,看看它是如何去与网页加载时间。

dawehner’s picture

 

APC与eAccelerator在:我发现eAccelerator在比快APC 13%,还可以节省每Apache进程比APC更多的内存。但是,这是一个边点。

别名补丁:尝试基地5.1的代码,没有任何别名补丁。看看有什么差别。我想说的5.1代码确定。

测试一个简单的方法,如果别名问题是禁用path.module,看看是否有在DEVEL页面执行时间的差异。

剖析:对于试图找出问题的所在,需要一个分析器。Xdebug的有一个分析器,但你必须使用的valgrind / cachegrind可视化的结果。

最初,我怀疑你有一个是吃了一次糟糕的模块。但我认为这是OpenVZ的是罪魁祸首这里。内存也帮助不大。尝试的Xen VPS主机。如果你没有一个访问,与我联系,私下里,如果你愿意给我一个数据库转储和tar.gz的网站,我可以尝试为你在Xen盒子,给你的数字。

Drupal的开发和定制:2bits.com
个人:Baheyeldin.com


Drupal的性能调整和优化,托管,开发和咨询:2bits.com,公司和Twitter的:@的2位
个人博客:

dawehner’s picture

 

主页
执行的61查询在25.36毫秒。页面执行时间为285.24毫秒。

/管理员
在10.13毫秒为单位执行的37个查询。页面执行时间为586.14毫秒。

/论坛
在50.86毫秒执行的115查询。页面执行时间为340.5毫秒。

/人
于48.07毫秒执行的117查询。页面执行时间为367.32毫秒。

结论:Xen是比OpenVZ的好。

Drupal的开发和定制:2bits.com
个人:Baheyeldin.com


Drupal的性能调整和优化,托管,开发和咨询:2bits.com,公司和Twitter的:@的2位
个人博客:

dawehner’s picture

 

我的建议是禁用和测试,一个接一个,每个模块贡献您的网站上运行。有可能是导致长页面的执行时间,缩小它归结为一个特定的模块可能使故障排除更容易一些流氓进程。

模块启用/停用一部分使用drush容易。从安全壳:

“drush statusmodules”会告诉你哪些模块有它们启用/禁用
“drush使能”将使模块,
“drush禁用”将禁用模块。

以一个备份你这样做了。

Page execution time much higher than query execution time. But why?

Hi,

I am in the process of making online social network/community website... Basically similar to myspace.... I recently moved from shared hosting to VPS (obvious reasons). It is a Debian Etch3 box with 128 Mb RAM burstable to 256 mb..... That's for now, I will get additional 256 MB of RAM next month. I set up Apache/2.2.3 PHP/4, Mysql5, eAccelerator 0.9.5

What I am concerned mostly now is page execution time. First I thought mysql was slow, but now I am not sure.... For example, for the front page, I get:

Executed 80 queries in 774.35 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 2060.83 ms.

Frontpage is mostly lots of panels, some of them display cached blocks, some of them display random SQL result. Why are queries executed in 0.7 seconds, and page execution time is 2 seconds ??? That surely has to be something with Apache configuration or php configuration.

in php.ini I set up memory_limit to 64M.
for eAccelerator I set up shm to 32M.

I really want to find out why is there such a big difference between query execution time and page execution time.... Page execution time should be a litlle bit higher than query execution time, right?

So, if you have any pointers for me where to look for solution, I would be more than thankful to you.

Thanks in advance

k.

Comments

NancyDru的图片

The first thing I'd check is whether or not php is actually getting 64M (which is a bit high, but okay). Many host companies are using a php that is compiled without the ability to override the memory_limit. As a matter of fact, my host completely ignores both my php.ini and settings.php (at least the settings like memory and execution time).

Also, in a case of shameless self-promotion, I suggest the Site documentation module to look for possible little problems.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

dawehner’s picture

Well, phpinfo() says that memory_limit IS 64M, just as I set it up. Did you mean to check it that way or some other way?

btw I just noticed I have plenty of php modules enabled as well... like: bcmath, bz2, calendar, ctype, dba, dbx etc... Don't know if I need all that, and if disabling some of them will reduce page execution time.

One other thing I read about on other thread is to try and put .htaccess file inside apache2.conf , so all the rules are loaded ONCE when the web server is started, and not on every page load. Will try that for sure.

Any other suggestions more than welcomed.

k.

yelvington的图片

... php execution overhead. Are you sure eAccelerator is working properly?

You might try turning it on/off, or switching to apc, and see if there's a significant difference.

dawehner’s picture

it most probably is php overhead.... eAccelerator is working fine.. I tried turning it off, and I got even higher page execution times.

It's weird. When you click a link to load some page, it makes a pause of 1 or 2 seconds, and then it continues to load a page. See it for yourself:http://tranceplanet.org/ and try clicking on some links.

phpinfo is at http://tranceplanet.org/info.php

btw I lowered memory_limit in php to 32M

NancyDru的图片

I went to your site and it loaded fairly fast for me. As busy as the front page is, I'm surprised it's not taking longer - especially the queries.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

dawehner’s picture

80 queries in 700 ms is still high. Here is what I get on a Xen VPS (512MB though, but that should not matter):

Executed 269 queries in 92.61 milliseconds. Page execution time was 349.69 ms.

You seem to be on Virtuozzo (or OpenVZ), and its performance is known not to be good. I have moved clients who suffered under Virtuozzo to Xen or dedicated and they have been happier. I even shut external traffic and did a measurement to prove to the client that it is Virtuozzo and not hits from visitors that is causing the slowdown.

I bet this is the problem, but here are other suggestions.

I have seen similar things before, where PHP times is much more than query time, and it is almost always due to a stray module.

On 4.6, it used to be when you had a lot of aliases (thousands), and Drupal was trying to load them all in an associative array.

However, you seem to be running 4.7, so that would not be the issue.

Other things to look at:

- Do you have any module that opens sockets to other sites?

- Try installing the trace module and see where time is spend.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

dawehner’s picture

- Yes, I just checked, I am on Openvz.... meanwhile they added more ram to my VPS, so it's 512 mb now.

- I tried APC an hour ago, but it seems that its performance is worse than eAccelerator, so I put back eAccelerator.

- I am running D 5.1

- I am not sure what stray module is?

- Yes, I do have lots of URL aliases (I think I applied patch for that from here:http://drupal.org/node/100301 )

- I don't have any modules that open sockets to other sites.

- I'll play with trace module and other stuff tomorrow, althought I won't be satisfied till I accomplish to have lower page execution times.

Thanks.

dawehner’s picture

Are there any other alternatives for trace module in D 5.1 ? How can I see where is most of the page execution time spent? Maybe to try Xdebug and debug my php scripts?

or maybe a lot of URL aliases is slowing the site down? I could have a site without all those fancy URL aliases if I knew page execution time would be higher.

I might turning off some modules as well and see how it goes with page load time.

dawehner’s picture

APC vs. eAccelerator: I have found that eAccelerator is 13% faster than APC, and also saves more memory per Apache process than APC. But that is a side point.

Aliases patch: Try the base 5.1 code, without any aliases patch. See if makes any difference. I would say the 5.1 code is OK.

An easy way to test if aliases are the problem is to disable the path.module and see if there is a difference in devel page execution times.

Profiling: For trying to pinpoint where the problem is, a profiler is needed. Xdebug has a profiler, but you have to use valgrind/cachegrind to visualize the results.

Initially I was suspecting that you have a bad module that is eating up time. But I think it is OpenVZ that is the culprit here. Memory would not help much. Try a Xen VPS host. If you don't have access to one, contact me privately if you are willing to send me a db dump and tar.gz of your site, and I can try it for you on a Xen box and give you the numbers.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

dawehner’s picture

Home page
Executed 61 queries in 25.36 milliseconds. Page execution time was 285.24 ms.

/admin
Executed 37 queries in 10.13 milliseconds. Page execution time was 586.14 ms.

/forum
Executed 115 queries in 50.86 milliseconds. Page execution time was 340.5 ms.

/people
Executed 117 queries in 48.07 milliseconds. Page execution time was 367.32 ms.

Conclusion: Xen is better than OpenVZ.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting:2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

dawehner’s picture

My suggestion would be to disable and test, one by one, each contributed module running on your site. There may be some rogue process that is causing the long page execution times, and narrowing it down to a particular module may make troubleshooting far easier.

The module enabling/disabling part is easily done using drush. From the secure shell:

"drush statusmodules" will tell you about which modules are there are which are enabled/disabled
"drush enable" will enable modules,
"drush disable" will disable modules.

Take a backup before you do this.

来自 https://www.drupal.org/node/154864


普通分类: