在一般的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年，還有一些細節需要盡快掌握。
评论