在一般的Drupal网站中，都是通过设置Cron定期运行来对Boost Cache、XML Sitemap进行更新，但我们在大数据量的Drupal网站中觉得需要进行一些改进。
首先来说Boost Cache，对于数十万甚至上百万的数据量，如果都进行静态页面缓存的话，占用硬盘过大，小文件太多，可能效率还不如不要静态页面缓存，这样的时候我们一般关闭了详细内容页面的静态缓存，只对分类页(Taxonomy Terms)、索引页(Views)进行缓存，就是这样，静态缓存的文件数也有数万个以上。这时如果通过Cron来定期让静态缓存失效的话，可能会出现删除时间过长而报错的情况，而且这些缓存本身也很可能不需要进行周期性更新，因为这些数据基本上都是长期固定的。
我现在的做法是将Boost中的设置Clear expired pages on cron runs:为“Disabled”，只有对网站进行过数据大量更新、模板更新等影响很大的操作时，才人工点击“Clear All Boost Cache”按钮来执行更新，而我在点击这个按钮后还可能碰到数据库报错的情况，这时磁盘上的静态文件可能没有被删除，还需要进入Linux服务器系统，用rm -rf /usr/local/apache2/htdocs/.../cache_path/*这样的命令来删除。
再来说说XML Sitemap，网站搭建好了以后，详细内容页面以及分类页面的数量、网址就基本定下来了，在生产一次XML Sitemap之后基本上就保持不变了，但Drupal系统中Sitemap设置的时候，Sitemap的最小生存期只能设置为1周，如果1周之内修改了1个页面，则整个Sitemap都需要重新生成，而这个生成的过程需要很多次Cron的运行，从而在此期间出现Sitemap不齐全的情况。
现在的做法是修改sites/all/module/xmlsitemap/xmlsitemap.admin.inc这个文件，找到包含“86400”（1天的秒数）的这一行，添加“,604800*4,86400*365,86400*3650”这几种数字，这样在管理员菜单中刷新就会看到，最小生存期从1周增加到4周、1年、10年。这是选择成10年，就相当于与是将最小生存期改为了无限大，只有在增加、减少了大量内容的时候，才有必要人工来重新生成。
另外，对于大数据量、变化很少的网站来说，Cron的运行周期也可以从以前设置的24小时改为7天甚至更长。
以前MediaWiki不断尝试了好几年，才把包括文件缓存、网站地图等各方面深入了解，现在Drupal也用了差不多1年，还有一些细节需要尽快掌握。
评论