大家一直都說drupal的效能不怎麼樣，跑起來慢，即使不是在使用者量大的時候，最近公司的蜜蜂培訓產品在乙個客戶的使用過程中，由於使用者量及資料量的激增，就遇到了比較大的效能問題，這篇文章就記錄了整個優化過程，最終將效能調整到了正常水平。
蜜蜂培訓系統由於是包含報名、簽到、投票、評估、考試等場景，而這些場景往往都是有時間點的限制，這就造成較大的使用者併發量。剛開始遇到效能問題的時候，大家的第一感覺肯定都是硬體水平跟不上，隨後我們對伺服器進行了擴容，但發現收效甚微，隨著使用者不斷增加系統也越來越慢，於是我們開始著手優化系統。
首先我們從資料庫開始，開啟了mysql 慢查詢日誌，來看看有沒有哪些邏輯的資料庫查詢有問題，這一看真嚇一跳，有乙個關鍵邏輯的sql居然最長要執行68秒！
找到了問題所在，那麼趕緊著手優化吧，來看看到底這個sql的執行時間到底耗費在了**，這裡我們用 mysql 的 explain 命令來分析一下這個sql的執行計畫， drush sql-cli 進入mysql命令列，敲入 explain + sql 就會列印出這個sql 的執行計畫：
參考 explain 命令的說明，可以看到上圖signup表是問題所在，這裡沒用到索引，使用了全表掃瞄和關聯操作，經過對sql 和場景的分析，我們對sql中的這幾個關鍵表對應的新增了新的索引：
}新增完索引後我們再來分析一下這個sql，看關鍵指標rows 由原來的近2w降低到了1條，剛剛建的索引起了作用：
更新到生產環境測試效果明顯，頁面載入時間由30s縮減到了3s左右，效能提公升近10倍，一天的觀察後這個慢sql再也沒出現在日誌當中了。
關鍵頁面載入問題解決了，接著我們繼續來看考試併發時速度慢的問題，起初我們也在尋找是不是也是因為有這樣的慢sql導致了考試載入速度慢，但始終沒發現相關的日誌記錄，之後我們翻出quiz的**，循著考試步驟一步步找原因，最後我們終於發現了問題所在：
每次答題頁面載入的時候會在不同的地方多次去資料庫查詢整個試卷的layout，當試卷題目數較多時就會造成必要嚴重的效能問題，之後我們新增了layout 的cache在使用者session中，減少了資料庫查詢次數，相應的頁面載入速度也有較大的效能提公升：
總結下來我們在遇到資料庫效能問題的時候，可以從資料庫索引優化與減少資料庫查詢次數兩方面考慮一下。
Drupal的效能優化 快取的手工清除
drupal有乙個內部的日誌系統，位於 t administer logs recent log entries，如果他沒有被定期地清除，那麼它將會快速的膨脹。這一日誌存放在 watchdog表中。如果你發現 watchdog表 的大小引起你的站點執行緩慢，你可以通過在 administer sit...
程式效能優化 區域性性原理
乙個編寫良好的電腦程式常常具有良好的區域性性，它們傾向於引用最近引用過的資料項附近的資料項，或者最近引用過的資料項本身，這種傾向性，被稱為區域性性原理。有良好區域性性的程式比區域性性差的程式執行得更快。時間區域性性示例 function sum arry return sum 在這個例子中，變數su...
59 Spark效能優化之shuffle效能優化
沒有開啟consolidation機制的效能低下的原理剖析.png 總結，沒有開啟consolidation機制的時候，shufflewtiter的效能，是比較低的，而且會影響到shuffle read的效能，而且效能也會比較低 因為shuffle map端建立的磁碟檔案太多了，導致shuffle ...