對于我們這種很多年建過很多網站的團隊來說，301重定向是一項重要的功能需求。很多時候我們的域名變更、路徑改變、語言版本的調整等等都是網址的永久性改變，需要用到301重定向。
以前我們多是用Apache Rewrite功能來設置，也就是在.htaccess文件中設置跳轉規則，例如：
RewriteCond %{HTTP_HOST
負載
這是 負載 分類的頁面，點擊下面标題查看詳細文章内容：
我們選用Drupal的一個重要原因是其對多語言的支持，在實際使用中也發現多語言支持的一些問題，特别是對數據庫負載的影響很大，我們已經想過不少辦法了。例如：Drupal設置Memcache緩存、修改緩存翻譯詞的長度、減少翻譯相關數據表的尺寸等。
這兩天對一台阿裡雲RDS負載問題進行排查的時候，再次開啟Devel來查看IP Location系列典型頁面的SQL查詢語句，從幾個方面進行了優化：
- 關閉不是很必要的模塊，例如theme color, dashboard, comment等，可以減少幾次數據庫查詢次數； <
最近一直在為降低MySQL服務器負載努力，Drupal網站中主要是排查Views引起的性能問題，而MediaWiki中也有一個與Drupal的Views對應的工具：Dynamic Page List (DPL動态頁面列表)，既可以靈活運用得到希望的信息展示效果，但同時也容易引起數據庫負載過高、性能下降。
當網站打開很慢的時候，還是需要查看阿裡雲RDS數據管理控制台DMS（Data Management Service），查看診斷報告或者當前實例會話，查看慢查詢語句，例如發現大量這樣的語句：
SELECT DISTINCT `jing
最近還在設法降低Drupal網站的MySQL負載，前些天嘗試了安裝entity cache，一般情況下可以把一個頁面的70-120個mysql查詢減少10個左右，然後把memcache使用的内存從1G增加到2G，應該會有一些幫助。
今天再次打開devel查詢，發現多語言網站的頁面中drupal_lookup_path特别多，50種語言就需要有50個這種查詢，而且每個查詢的語言代碼不同，不能很好利用MySQL的查詢緩存機制。
其實這個查詢語句：
SELECT alias FROM url_alias WHERE
Drupal網站對數據庫服務器的壓力由來已久，特别是Views做成的頁面是最可能導緻負載升高的原因，無論是以前自己服務器上的MySQL還是換用阿裡雲的RDS。
以前也采取一些緩存的措施來降低負載，但偶爾會出現一些問題，我翻看以前的博客中記錄有《Drupal網站Views生成頁面Title改為變量的問題》、《一個Drupal網站Views消失的排查》。
後來Drupal 6升級Drupal 7後似乎有些變化，但我一直也沒有深究，基本上都是把Views的查詢緩存設置為6天，把顯示緩存設置為0，在系列網站的xxx.views_default.
春節前忙着把一些網站從自己獨立托管的服務器搬遷到阿裡雲的平台中去，以前自己的服務器都是購買的頂配硬件（幾年前就是16核、64G内存、8塊硬盤），安裝Linux+Apache+MySQL+PHP在同一台機器上，現在用了雲服務器ECS做Web服務器，用雲數據庫RDS做MySQL服務，應該來說更合理，不過實際運行中也遇到問題。
先搬遷了幾個小的網站，數據量不大、訪問量不大，所以搬遷過去沒有什麼大的負載，ECS/RDS以及帶寬什麼都很富裕。但在搬遷一個數據量偏大、訪問量也較大的網站時遇到問題，RDS的CPU總是100%，不運行自動檢測超時MySQL進程并自動殺死該進程的腳本就
在我們一些用Drupal搭建的大數據量網站中，Boost模塊産生的緩存文件數量非常多，以至于運行cron期間無法更新完畢，我們後來就采用了不自動更新緩存文件，而是人工根據需要在服務器上直接删除緩存文件的辦法。
但當緩存文件數量達到數十、上百萬的時候，需要很長時間删除，在這個過程中如果還有用戶訪問、産生新的緩存文件，将導緻硬盤占用達到100%，長期這樣的話，可能讓服務器硬盤不堪重負、服務器出現負載上升、網站無法訪問的情況。
這個問題一直困擾了我們好長時間，以前都是采取人工每次删除少量文件，逐步試着來進行，這導緻要花費好些時間精力。昨天在網上查找了
從7月初到10月底的4個月時間中，我們已經在服務器上導入了大量數據，建成了一批新的子網站，在接下來的一段時間内我們不準備繼續大增數據量了，而是對已經導入數據的網站進行精細優化調整，這個月已經開始了這方面的工作。
MediaWiki平台的網站都是去年以及以前建成的，這次基本沒有大的調整，隻是一部分網站對模闆進行了更新，以便嵌入microdata微數據标記，雖然也需要運行後台更新、重新生成緩存文件，不過這個對服務器的負載影響不算很大，是可以承受的。
而在對今年新做的Drupal平台的改進中，如果隻是修改内頁模闆、block以及me
在以前的MediaWiki所建站點中，我們啟用了外部的Squid緩存和MediaWiki本身的File Cache兩種頁面緩存方式。
File Cache設置成時間無限長，隻有頁面或者包含的模闆變化時才會更新，這項設置對緩解服務器壓力起到了關鍵作用，如果不啟用的話，網站很快就會變得無法訪問。緩存的更新問題也基本上還好，在正常控制下工作。