这是（最有可能）因为Drupal cron任务正在运行每隔几小时/天（取决于设置）。Drupal然后执行所有排队的玉米的工作..这可能需要很长的时间。

看看这drupal.stackoverflow                        网页

E：另外，这种调整可能会有帮助，但我还没有尝试过自己：http：／／drupal.org /节点/ 1576686                    

关闭生产更新管理器模块。cron运行时，它将检查更新，这需要时间。只有启用该模块在开发网站节省时间（开发、分期等）。没有必要的生产要花时间研究这个。

我知道这是一个古老的问题，但这是我的解决方案。这种情况的网站，不会产生多少流量和服务器上的网站应用程序池自动关闭了一段时间后（我相信默认为20分钟）。因此，第一个点击网站后的这段时间要等待应用程序池重启，可以花一些时间在PHP网站。这也适用于玉米的工作。核心工作是建立玉米运行每隔N分钟，但它只能运行当有人点击网站。所以，第一个人打网站设定的区间为玉米后要等待玉米工作运行。因此，在生产现场，你应该禁用的核心工作和手动运行或使用外部服务运行的玉米（玉米是通过外部URL）。最好的办法是使用免费的外部服务正常运行时间的机器人                        打你的网站每5-10分钟，从而保持联系。

• 对于应用程序池关闭会发生：使用PHP-FPM                                    与pm = ondemand                                    或使用PHP，CGI -                                    与FcgidIdleTimeout                                    与一个值> 0。                                    –李嘉图Velhote15年5月26日在15:56                                

看你在你的网站看一看头部                        区域如果有“有那么问题最有可能在前端而不是后端的import语句很多。

Drupal使用大量的CSS和JS文件的默认。浏览器可以开始绘制你的网页请求只有在所有。CSS和JS文件。头部                        有下载的部分

与“进口的问题是，你的浏览器可以下载只是一个单独的CSS文件，在一个时间。这是不同的标签。CSS文件可以下载并在这种情况下，这意味着更快的。

第二次访问你网站的css和js文件加载浏览器缓存，这解释了为什么网页的加载速度更快。

建议的解决方法：                        去管理/设置/性能使CSS和JS聚集。

Drupal creates pages and serves them to clients. The completed pages are also stored in the cache_page table of the database -- referred to as the Page Cache. This function is enabled on page admin/settings/performance. The nominal settings for the Page Cache section is:

• Caching Mode: Normal

• Minimum Cache Lifetime: None

• Page Compression: Enabled

With these settings the Page Cache will be emptied every time cron runs. Please take this into consideration when you set the number of times cron runs each day. The cron job of our production website runs once per day just after midnight when traffic on the website is low.

The problem with this setup is the Page Cache is empty after cron runs. This means the first time a user accesses a page the completed page will not be in the Page Cache and the access will be slow. We can solve this problem by loading all the webpages of the site when cron completes (known as "cache warming"). You can do this by creating a script that runs the standard cron job followed by some code that loads each page in sitemap.xml into the Page Cache:

#!/bin/bash
#
# this is the standard Drupal cron invocation that runs from cron
#     this will flush the Page Cache when Minimum Cache Lifetime set to <none>
#
wget -O - -q -t 1 http://www.example.com/cron.php
#
# use the sitemap and reload the Page Cache by accessing each page once
#
wget --quiet http://www.example.com/sitemap.xml --output-document - | egrep -o "http://www.example.com[^<]+" | wget -q --delete-after -i -O -

You need to change www.example.com in the code above to the domain of your website. Run this script from cron instead of the standard cron invocation. Now the webpages of your website in sitemap.xml are loaded into your Page Cache waiting for the first user access. This first user access will now be served from the Page Cache -- much faster.

This can also be done with the Cache Warmer module. It's run as a Drush command, and it takes a lot of options.

See also:

• http://drupal.org/documentation/modules/system

You should start by reading the Drupal handbook pages about cron to get background and commands to run.

• If you have shell/SSH access to the (Linux) server, you can run use run crontab -u www-data -e to edit the cron table for the web user. You should be able to use the details in the above link to set up proper cron runs as often as you'd like.

• If you're on shared hosting without shell access, you'll need to use your web host's control panel (CPanel, Plesk etc.) to log in and add a 'Scheduled Task'. This provides as web interface to the cron tabs, so the same settings will be needed.

• If these are not available you'll need to ask your hosting company to help, but there are also free and paid services you can use call the cron.php page remotely for you. See Set Cron Jobfor example.

Take a look like the Elysia Cron module if you want more out of cron in general -- it's got good documentation and allows you to finely control what tasks run when.

Finally, remember to disable the site running it when visitors arrive at Administration » Configuration » System » Cron when you've managed to set this up.

• I have shell access. I know how to set up cron jobs. So I will figure it out. But thanks for summarizing all the information. – cateye Dec 27 '11 at 13:57                                 
• But what I don't understand is, why Drupal behaves like it does now. If the basic configuration is scheduled to run the cron each 3 hours, why does it wait for a visitor? – cateye Dec 27 '11 at 13:58                                
• 1                                
  Thinking about it. There is off course for Drupal no way to run a cron job without bootstrapping. And the bootstrapping occurs when a visitor hits the site. So, the summary is: If you want really scheduled cron jobs, you have to set it up server side. – cateye Dec 27 '11 at 14:04                                
• 2                                
  Exactly. Nothing happens on a server without someone or something running it. The Drupal 7 default is to run cron when users arrive occasionally to ensure key tasks get run. Drupal 6 relied on the Poor Man's Cron module to do this in the absence of a proper cron job... and almost everything in Drupal needs the bootstrap to happen first. A proper cron job on the server is certainly the best option. – Jim Kirkpatrick Dec 27 '11 at 14:48                                
• 1                                
  The ANSWER BELOW describes how to fix it. Not this one :( – Tomáš Fejfar Dec 17 '14 at 10:48                                

Drupal 7 incorporated in its modules the code that were in Poormanscron, whose purpose is exactly to run Drupal cron tasks on a site where it is not possible to set cron tasks, when a user visits your site, and every X hours (as set in the page you saw).

If you want to avoid that behavior, you just need to set "Run cron every" to "Never"; contrary to what it could seem, that just influences what happens when users visit your site.^[1] You can still run Drupal cron tasks from outside Drupal, remembering that in Drupal 7 cron.php needs to be invoked, from outside Drupal, passing the value shown in "Administration > Reports > Status report."

[1]: In fact, neither cron.php, nor drupal_cron_run() checks the Drupal variable used in that settings page. The only Drupal variables used are:

• "cron_key" that contains the cron key used to avoid the Drupal cron tasks are ran from unauthorized users

• "maintenance_mode" that is set to TRUE when the site is in maintenance mode

• "cron_last" that contains the timestamp of when cron tasks were ran last time

• The only difficulty is when the cron job times out every time you view the page and you can't even login as admin to disable it! sigh... I'll figure it out but good to know it can be disabled, once I actually get in there – user11312 Mar 17 '13 at 4:16                                
• Yeah, I solved this quickly by setting up a Montastic uptime monitor that "checks" the cron activation URL every 6 hours... – Anders May 16 '13 at 20:27                                

Slow loading when viewing site for the first time (or after 10 minutes of inactivity)

Hi,

I'm building a site for my client and we both noticed that loading time is very slow when we enter the site address for the first time. It takes about 7 seconds just to start loading files and displaying the content. Like it has some delay.

However, after that period it's very fast and everything is ok. Once the page(s) is/are loaded, we can refresh them quickly and without any delay..... It will happen again though if we weren't active for like 10 minutes...

I tried with caching & compression & optimization enabled, but no luck - first-time delay is there no matter what I do.

Is this a problem with drupal, .htaccess file (I'm using the same I received with drupal) or server?

Thanks.

If using NFS I highly recommend using apc.stat=0 and then if you want to update the apc cache run apc_clear_cache('opcode');.

Seeing how drupal_parse_info_file() is ran on every page load I'm guessing this core patch will help you out: https://www.drupal.org/node/1081266#comment-9411015                    

Another thing that can help with running code from a NFS drive is this issue: https://www.drupal.org/node/1443308                    

Also related to potential NFS issues these 2 modules usually help in that situation
https://www.drupal.org/project/imageinfo_cache
https://www.drupal.org/project/advagg                    

• Earlier I had debugged the install for missing module and found ATCommerce theme was the culprit and patched So I doubt that patch will make a dent. imagecache_info may be handy for nodes that don't have style generated, but this is not an issue with login page. advagg is more suitable for delivery which is the next step and it did not work for my case, the page generation time is high. Today I also did registry check which was fine. Added new XHprof for a cold start which is even worse. – amit Feb 20 '15 at 21:48                                
• New one looks like the vast majority of the time spent with the latest output is time spent in the file system (NFS), use stat=0; the other part is due to the cache miss inside _theme_load_registry(). A cache miss on a cold start is hard to fix; thus at this point I would still be looking at fixing NFS. – mikeytown2 Feb 20 '15 at 21:58                                 
• Also odds are you will need to increase realpath_cache_size as well. You can check it by comparing realpath_cache_size() to ini_get('realpath_cache_size'). If they are close (I use 10% in APDQC) increase the realpath_cache_size and restart php. Rinse and repeat until they are no longer within 10% of each other. – mikeytown2 Feb 20 '15 at 22:18                                 
• Sorry it was not a cold start but site access after a silent couple hours. This is problem which is bothering me the most. The realpath_cache_size looks fine I have seen it go unto 350k in previous instance, currently it is 80k – amit Feb 20 '15 at 22:50                                

It seems your top time consuming function is ob_flush() which is called only once, but for 200-500ms.

This call is invoked in drupal_page_footer() as follow:

function drupal_page_footer() {
  // ...

  if (variable_get('cache', 0) && ($cache = drupal_page_set_cache())) {
    drupal_serve_page_from_cache($cache);
  }
  else {
    ob_flush();
  }

So in both of your cases cache doesn't work, either by the 1st load or for the reason that the page was loaded by authenticated user (drupal_page_is_cacheable()). So probably nothing that we can do here.

Function ob_flush() send the contents of the output buffer to the client, and the latency of this transport to the client is probably higher than the actually PHP buffer flushing. See: Why does calling ob_flush() slow down my latency so much?.

Here are few ideas how to improve the load times:

• enable/disable zlib.output_compression (and see which option is quicker),

• test for network bottlenecks, if the problem is not with NFS server by checking the load times of simple PHP files (such as update.php or plain php files),

• if your buffer is flushed too slow, something holds the buffer until the page has finished loading, this can be caused by some Apache modules or client it-self,

• if it's server fault, review your Apache modules and APC settings (you can use strace to investigate the problem by debugging your Apache process when it handles the request),

• if it's client fault, test your page by disabling plugins or use different web browser, as well as disable any antivirus softwares (which can hold the buffer until it's checked for web viruses)

• install XCache instead of APC, set xcache.count to your cpu count something between 4-8 (check sample xcache.ini).

• 1                                
  @mikeytown2 Added timing for update.php. All that stuff looks like a check for new files, so nfs is hit pretty hard in this case. zlib.output_compression caused problems with some downloads getting double zipped as we use mod_deflate. Web browser should not be an issue as we just looking XHprof output which is all server side. The database queries are under 100ms so Apache config or NFS are remaining culprits. Will try to set apc.stat=0 to rule out NFS issue. I am also tempted to try apdqc with entity cache, but that has to wait till the basic stuff is resolved. Thank you both – amit Feb 20 '15 at 22:48                                
• @amit Based on your update.php, it seems your file operations are very slow. Double check if APC works correctly or you may compare the results with XCache (set xcache.count to your # of CPUs, like 4-8). – kenorb Feb 20 '15 at 23:09                                 
• 1                                
  I am using APCcache module to store some extra bins. When I run cache and apc cache tests I get fatal errors with "Class 'Database' not found" so something is misconfigured. I have updated my settings above. Could you take a look. – amit Feb 21 '15 at 4:21                                
• 1                                
  Confirmed that my APC setup is hosed with this test My APC settings indicate Version 3.1.9, MMAP Support Enabled, MMAP File Mask /tmp/apc.a7zvYc, Locking type pthread mutex Locks So it seems like using file based caching not memory. Apparently disabled APC is slightly better in above test. – amit Feb 23 '15 at 23:25                                 
• @amit Good to know. Try XCache, which I think it should perform better, as apart of file caching, it has a code optimization and you can customize it more. – kenorb Feb 23 '15 at 23:40