從用MediaWiki做網站開始，服務器負載一直就是個問題，為了解決這個問題，我們添加了各種緩存，如MediaWiki的多種緩存機制，包括File Cache，也加上了外部的Squid。後來做Drupal網站并不需要Squid，但因為服務器上已經安裝了Squid，我們也隻好把Drupal架設在Squid之後，另外Drupal也采用了内部core緩存和Boost緩存。
這些緩存機制可以解決不少問題，但緩存主要對數據量小、每頁訪問多的網站有明顯效果，而對于數據量很大、每頁訪問少的網站起不到明顯效果，有時甚至因為緩存文件過多起到反效果，而且緩存更新機制也有些小問題。
上周在升級Drupal 6網站的時候，我們把大數據量的網站Boost緩存都去掉了，這樣才方便升級。
升級後發現有些站自動判斷訪問終端跳轉到手機版的失敗有些問題，電腦訪問也跳到手機版，而且出現比較随機的情況，一時還無法查到原因，查看以前的工作日志發現這個問題去年11月Drupal升級後也有類似情況沒有解決。今天把.htaccess都修改了還是不能看到變化，那隻能是前端Squid緩存的問題了，加了cache deny後馬上就看到跳轉恢複正常了。本來準備隻對Drupal網站和部分文件拒絕緩存的，後來幹脆用一句cache deny all讓Squid徹底不緩存文件了，這樣再觀察看看效果，如果對負載影響不大，以後就幹脆去卸載Squid算了。
另外，一些MediaWiki網站我們做了繁體版、手機版，在更改電腦版後，同步更新有些問題，我準備稍後去把一些版本的File Cache關閉看看，隻要對負載影響不大就準備都關閉。
评论2
讓人郁悶的mediawiki靜态化
filecache 加上之後，感覺并沒有使程序的訪問效率得到提高，甚是讓人郁悶！對于頁面數量少、單頁面訪問多的有效
我們以前有一個網站就是頁面數量不多，但每個頁面的訪問量大（例如某些頁面每天成百上千的匿名用戶重複訪問），那樣用file cache有很明顯的效果，但如果每個頁面的訪問量都不是很大的話，就看不到特别的效果了。